ストリーミング双方向ビデオサーバー間でユーザセッションを移行する方法

专利摘要:
ストリーミング双方向ビデオサーバー間でユーザセッションを移行する方法を提供する。ビデオストリーム又はユーザの双方向操作性を著しく妨害せずに、ストリーミング双方向ビデオユーザセッションを、あるストリーミング双方向ビデオサーバーから別のストリーミング双方向ビデオサーバーへハンドオフする方法。ａ
公开号:JP2011507077A
申请号:JP2010537057
申请日:2008-12-04
公开日:2011-03-03
发明作者:デル；ラーン；ロジャー ヴァン；スティーブン；ジー パールマン
申请人:オンライブ インコーポレイテッド；
IPC主号:G06Q50-00

专利说明:

[0001] 本発明は、一般的に、オーディオ及びビデオメディアを操作し及びそれにアクセスするユーザの能力を改善するデータ処理システムの分野に係る。]
[0002] 関連出願：本出願は、本出願の譲受人に譲渡された“APPARATUS AND METHODFOR WIRELESSVIDEO GAMING”と題する２００２年１２月１０日出願の第１０／３１５，４６０号の一部継続（ＣＩＰ）出願である。]
背景技術

[0003] 記録音声及び動画メディアは、トーマスエジソンの時代から世相を表している。２０世紀の初頭に、記録音声メディア（シリンダー及びレコード）及び動画メディア（ニコロデオン及び映画）が広く配給されたが、両技術は、まだ幼時期であった。１９２０年代後期に、動画が大量市場ベースで音声と結合され、その後、音声を伴うカラー動画となった。ラジオ放送は、大規模な広告支援形態の放送大量市場音声メディアへと徐々に進化した。１９４０年代中期にテレビ（ＴＶ）放送規格が確立されると、テレビは、予め録画された又は生の動画を家庭へ届ける放送大量市場メディアの一形式としてラジオに加わった。]
[0004] ２０世紀中期までは、米国の家庭の大部分は、記録音声メディアを再生する蓄音器レコードプレーヤ、生放送音声を受信するラジオ、及び生放送オーディオ／ビデオ（Ａ／Ｖ）メディアを上映するテレビ受像機を有していた。多くの場合に、これら３つの「メディアプレーヤ」（レコードプレーヤ、ラジオ及びＴＶ）は、共通のスピーカを共有する１つのキャビネットに結合されて、家庭の「メディアセンター」となった。メディアの選択肢は、消費者に制限されるが、メディア「エコシステム」は、かなり安定したものであった。ほとんどの消費者は、「メディアプレーヤ」をどのように使用するか知っており、それらの能力をフルに楽しむことができた。同時に、メディアの発行者（主に動画及びテレビスタジオ、並びに音楽会社）は、一般に普及した海賊版又は「二次販売」即ち中古メディアの再販から悩まされることなく、それらのメディアを劇場及び家庭の両方に配給することができた。典型的に、発行者は、二次販売から収入を得ず、従って、そうでなければ新規販売のために中古メディアの買い手から発行者が得るかもしれない収入が減少した。２０世紀の中期に販売された中古レコードは確かにあるが、そのような販売は、レコード発行者に大きな影響を及ぼさなかった。というのは、典型的に大人が一度又は数回見るだけの動画又はビデオ番組とは異なり、音楽トラックは、数百回又は数千回も聞かれるからである。従って、音楽メディアは、動画／ビデオメディアより遥かに「腐敗」しない（即ち、大人の消費者にとって価値が継続する）。レコードを購入すると、消費者がその音楽が好きな場合、消費者は、おそらくそれを長期間保持する。]
[0005] ２０世紀の中期から今日にかけて、メディアエコシステムは、消費者及び発行者の利益及び損害の両方にとって一連の根本的な変化を受けた。オーディオレコーダー、特に、高品質ステレオサウンド付きのカセットテープが広く導入されると、確かに高度の消費者便宜性があった。しかし、それは、消費者メディアと共に今や広く普及したもの、即ち海賊版の始まりも印した。確かに、大勢の消費者が彼ら自身のレコードを純粋に便宜性のためにテープ記録するのにカセットテープを使用したが、次第に多くの消費者（例えば、互いのレコードコレクションに手早くアクセスできる寄宿舎の学生）が海賊版コピーを作成した。又、消費者は、発行者からレコードやテープを買うのではなく、ラジオを経て演奏される音楽もテープ記録した。]
[0006] 消費者向けＶＣＲの出現は、新規なＶＣＲがＴＶショーを録画するようにセットでき、後で見ることができるので、更なる消費者便宜性を導くと共に、映画やＴＶ番組に「オンデマンド」ベースでアクセスできるビデオレンタルビジネスの創設も導いた。１９８０年代中期以来の大量市場家庭用メディア装置の急速な開発は、かつてない選択肢レベル及び消費者にとっての便宜性を導くと共に、メディア発行市場の急速な膨張も導いた。]
[0007] 今日、消費者は、過度のメディア選択肢及び過度のメディア装置に直面し、その多くは、特定の形式のメディア又は特定の発行者に結び付いたものである。熱心なメディア消費者は、家の種々の部屋にＴＶ及びコンピュータに接続された装置を積み重ねて有し、その結果、１つ以上のＴＶ受像機及び／又はパーソナルコンピュータ（ＰＣ）へのケーブルの「ネズミの巣穴」、並びにリモートコントローラのグループが生じている。（本出願に関して、「パーソナルコンピュータ」又は「ＰＣ」という語は、デスクトップ、Ｍａｃｉｎｔｏｓｈ（登録商標）又は他の非Ｗｉｎｄｏｗｓ（登録商標）コンピュータ、Ｗｉｎｄｏｗｓ適合装置、ＵＮＩＸ（登録商標）バリエーション、ラップトップ、等を含めて、家庭又はオフィスで使用するのに適した任意の種類のコンピュータを指す。）これらの装置は、ビデオゲームコンソール、ＶＣＲ、ＤＶＤプレーヤ、オーディオサラウンド−サウンドプロセッサ／増幅器、衛星セットトップボックス、ケーブルＴＶセットトップボックス、等を含む。そして、熱心な消費者にとって、互換性の問題があるために、複数の類似機能装置が存在する。例えば、消費者は、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙ ＤＶＤプレーヤの両方を所有したり、又はＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）の両ビデオゲームシステムを所有したりすることがある。実際に、あるゲームはゲームコンソールのバージョンにわたって互換性がないために、消費者は、ＸＢｏｘと、その後のバージョン、例えば、Ｘｂｏｘ３６０（登録商標）との両方を所有することがある。多くの場合、消費者は、どのビデオ入力及びどのリモートコントローラを使用すべきか混乱する。ディスクが正しいプレーヤ（例えば、ＤＶＤ、ＨＤ−ＤＶＤ、Ｂｌｕ−ｒａｙ、Ｘｂｏｘ又はＰｌａｙｓｔａｔｉｏｎ）に入れられ、その装置に対してビデオ及びオーディオ入力が選択され、そして正しいリモートコントローラが見つかった後でも、消費者は、まだ、技術的な挑戦に直面する。例えば、ワイドスクリーンＤＶＤのケースでは、ユーザは、先ず、自分のＴＶ又はモニタスクリーンにおける正しいアスペクト比（例えば、４：３、フル、ズーム、ワイドズーム、シネマワイド、等）を決定し、次いで、セットすることが必要になる。同様に、ユーザは、先ず、正しいオーディオサラウンドサウンドシステムフォーマット（例えば、ＡＣ−３、ドルビーデジタル、ＤＴＳ、等）を決定し、次いで、セットすることが必要になる。多くの場合、消費者は、彼等のテレビ又はオーディオシステムのフル能力でメディアコンテンツを楽しんでいないことに気付かない（例えば、間違ったアスペクト比で押しつぶされた映画を見たり、又はサラウンドサウンドではなくステレオでオーディオを聞いたりしている）。]
[0008] 装置の積み重ね体には、インターネットベースのメディア装置が益々追加されている。Ｓｏｎｏｓ（登録商標）デジタルミュージックシステムのようなオーディオ装置は、インターネットからオーディオを直接ストリーミングしている。同様に、Ｓｌｉｎｇｂｏｘ（登録商標）エンターテイメントプレーヤのような装置は、ビデオを録画し、そしてホームネットワーク又はインターネットを通してそれをストリーミングし、遠隔位置でＰＣにおいてそれを見ることができる。インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスは、デジタルサブスクライバーライン（ＤＳＬ）又は他のホームインターネット接続を通してケーブルＴＶ型のサービスを提供している。又、最近では、Ｍｏｘｉ（登録商標）メディアセンターや、Ｗｉｎｄｏｗｓ ＸＰメディアセンターエディションを実行するＰＣのような単一の装置へ複数のメディアファンクションを一体化する努力もなされている。これらの装置は、各々、それが遂行するファンクションに対する便宜性の要素を与えるが、偏在性及びほとんどのメディアへの簡単なアクセス性が欠如している。更に、このような装置は、多くの場合に高価な処理及び／又はローカル記憶が必要なために、製造コストがしばしば数百ドルに達する。更に、これらの近代的な消費者向け電子装置は、典型的に、アイドル状態である間も、多量の電力を消費し、これは、時間と共に経費高となり且つエネルギーリソースを浪費することを意味する。例えば、ある装置は、消費者がそれをターンオフするのを怠るか又は異なるビデオ入力へスイッチした場合に動作し続けることがある。そして、どの装置も完全な解決策ではないので、家庭内の装置の他の積み重ね体と一体化しなければならず、これでは、依然、ユーザをワイヤのネズミの巣穴及びリモートコントローラの海に残すことになる。]
[0009] 更に、多くの新しいインターネットベースの装置は、それが適切に機能するときには、典型的に、メディアを、それが入手できる以上に一般的な形態で提供する。例えば、インターネットを通してビデオをストリーミングする装置は、多くの場合、ビデオ、ゲームの「制作」又は演出家の解説のようなＤＶＤをしばしば付随する双方向「エキストラ」ではなく、ビデオ資料だけをストリーミングする。これは、多くの場合、双方向性をローカルに取り扱う特定の装置に意図された特定のフォーマットで双方向資料が発生されることによるものである。例えば、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙディスクは、それら自身の特定の双方向フォーマットを有している。普及型フォーマットを全てサポートするように開発されるホームメディア装置又はローカルコンピュータは、おそらく消費者が動作するには法外なほど高価で且つ複雑なものにするレベルの精巧さ及び融通性を要求することになる。]
[0010] この問題に加えて、将来的に新規なフォーマットが導入された場合には、ローカル装置は、その新規なフォーマットをサポートするハードウェア能力をもたないことがあり、これは、消費者がアップグレード型のローカルメディア装置を購入しなければならないことを意味する。例えば、高解像度ビデオ又はステレオビデオ（例えば、各目に対して１つのビデオストリーム）が後日に導入された場合には、ローカル装置は、そのビデオをデコードする計算能力をもたないか、又は新たなフォーマットでビデオを出力するためのハードウェアをもたないことがある（例えば、各目に６０ｆｐｓが与えられて、１２０ｆｐｓのビデオがシャッター付き眼鏡と同期されることでステレオ感が達成されると仮定すれば、消費者のビデオハードウェアが６０ｆｐｓビデオしかサポートできない場合、このオプションは、アップグレード型ハードウェアを購入しなければ、利用できない）。]
[0011] メディア装置の老朽化及び複雑さの問題は、精巧な双方向メディア、特に、ビデオゲームに至ったときには、重大な問題となる。]
[0012] 近代的なビデオゲームアプリケーションは、主として、４つの主要な非ポータブルハードウェアプラットホーム：即ち、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）１、２及び３（ＰＳ１、ＰＳ２及びＰＳ３）、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）及びＸｂｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ Ｇａｍｅｃｕｂｅ（登録商標）及びＷｉｉTM、並びにＰＣベースのゲーム、に分割される。これらプラットホームの各々は、他のものとは異なり、１つのプラットホームで実行するように書かれたゲームは、別のプラットホームでは実行されない。又、装置のある世代から次の世代への互換性の問題もある。ソフトウェアゲーム開発者の大半が、特定のプラットホームとは独立して設計されたソフトウェアゲームを創作しても、特定のゲームを特定のプラットホームで実行するためには、特定のプラットホームで使用するようにゲームを適応させるのに、ソフトウェアの専有レイヤ（しばしば「ゲーム開発エンジン」と称される）が必要になる。各プラットホームは、消費者へ「コンソール」（即ち、ＴＶ又はモニタ／スピーカに取り付けられるスタンドアローンボックス）として販売されるか、或いはＰＣそれ自体である。典型的に、ビデオゲームは、精巧なリアルタイムソフトウェアアプリケーションとして実施されるビデオゲームを含むＢｌｕ−ｒａｙ ＤＶＤ、ＤＶＤ−ＲＯＭ、又はＣＤ−ＲＯＭのような光学的メディアで販売される。家庭用ブロードバンドの速度が高まるにつれて、ビデオゲームは、ダウンロードに利用されることが益々増えている。]
[0013] ビデオゲームソフトウェアとのプラットホーム互換性を得るための特定の要件は、進歩型ビデオゲームのリアルタイム性及び高計算要件のために極めて厳しいものである。例えば、あるＰＣから、より速い処理ユニット又はコアをもつ別のＰＣへの製造アプリケーション（例えば、マイクロソフトワード）の一般的な互換性と同様に、ビデオゲームのある世代から次の世代への（例えば、ＸＢｏｘからＸＢｏｘ３６０への、又はＰｌａｙｓｔａｔｉｏｎ２（ＰＳ２）からＰｌａｙｓｔａｔｉｏｎ３（ＰＳ３）への）完全なゲーム互換性が期待される。しかしながら、ビデオゲームでは、このようにならない。ビデオゲームの製造者は、典型的に、あるビデオゲーム世代が発売になるときに所与の価格点に対して考えられる最高の性能を求めているので、前世代システムに対して書かれた多くのゲームが後世代システムでは機能しないような急激なアーキテクチャー変更がシステムに対してしばしばなされる。例えば、ＸＢｏｘは、プロセッサのｘ８６ファミリーをベースとしたものであり、一方、ＸＢｏｘ３６０は、ＰｏｗｅｒＰＣファミリーをベースとしたものである。]
[0014] 従来のアーキテクチャーをエミュレートするための技術を利用できるが、ビデオゲームがリアルタイムアプリケーションであるとすれば、エミュレーションにおいて厳密に同じ挙動を達成することはしばしば不可能である。これは、消費者、ビデオゲームコンソール製造者、及びビデオゲームソフトウェア発行者にとって損害である。消費者については、全てのゲームをプレイできるようにするために、ビデオゲームコンソールの新旧の世代をＴＶに接続したままにする必要があることを意味する。コンソールの製造者については、エミュレーションに関連したコスト、及び新規コンソールの採用に手間取ることを意味する。又、発行者については、全ての潜在的な消費者に届くように、新たなゲームの複数のバージョンを発売する必要があり、即ちビデオゲームのブランド（例えば、ＸＢｏｘ、Ｐｌａｙｓｔａｔｉｏｎ）ごとのバージョンを発売するだけでなく、所与のブランドのバージョン（例えば、ＰＳ２及びＰＳ３）ごとのバージョンをしばしば発売する必要がある。例えば、他のプラットホームの中でも、ＸＢｏｘ、ＸＢｏｘ ３６０、ＰＳ２、ＰＳ３、Ｇａｍｅｃｕｂｅ、Ｗｉｉ及びＰＣに対して、エレクトロニックアーツ“Ｍａｄｄｅｎ ＮＦＬ０８”の個別バージョンが開発されている。]
[0015] セルラー（セル）電話及びポータブルメディアプレーヤのようなポータブル装置も、ゲーム開発者への挑戦を提示する。次第に、このような装置は、ワイヤレスデータネットワークに接続されており、ビデオゲームをダウンロードできるようになっている。しかし、市場には、広範囲な異なる表示解像度及び計算能力をもつ種々様々なセル電話及びメディア装置が出回っている。又、このような装置は、典型的に、電力消費、コスト及び重量に制約があるので、カリフォルニア州サンタクララのＮＶＩＤＩＡで製造される装置、等のグラフィックプロセッシングユニット（ＧＰＵ）のような進歩型グラフィック加速ハードウェアに欠けるものである。その結果、ゲームソフトウェアの開発者は、典型的に、多数の異なる形式のポータブル装置に対して所与のゲームタイトルを同時に開発する。ユーザは、自分の特定のセル電話又はポータブルメディアプレーヤに対して所与のゲームタイトルが得られないことが分かる。]
[0016] 家庭用ゲームコンソールの場合には、ハードウェアプラットホームの製造者は、典型的に、彼等のプラットホームでゲームを発行する能力についてソフトウェアゲーム開発者にロイヤリティを課する。セル電話の電信会社も、典型的に、ゲームをセル電話にダウンロードするためにゲーム発行者にロイヤリティを課する。ＰＣゲームの場合には、ゲームを発行するために支払われるロイヤリティはないが、ゲームの開発者は、典型的に、生じ得る広範囲のＰＣコンフィギュレーション及びインストール問題をサポートするための消費者サービス負担が大きいために、高いコストに直面する。又、ＰＣは、典型的に、ゲームソフトウェアの海賊行為に対してバリアがほとんどない。というのは、それらは、技術的知識のあるユーザによって再プログラムが容易であり、ゲームの海賊版を容易に作成して（例えば、インターネットを通して）容易に配布することができる。従って、ソフトウェアゲーム開発者については、ゲームコンソール、セル電話及びＰＣにおいて発行する上でコストがかかり且つ欠点があることになる。]
[0017] コンソール及びＰＣソフトウェアのゲーム発行者にとって、コストは、これだけでは終わらない。小売チャンネルを通してゲームを配布するために、発行者は、利ざやを得るように小売店の販売価格より低い卸売価格を課する。又、発行者は、典型的に、製造コストを支払いそしてゲームを保持する物理的メディアを配布しなければならない。又、発行者は、例えば、ゲームが売れない場合、ゲームの価格が下がった場合、或いは小売店が卸売価格の一部又は全部を払い戻し及び／又はゲームを買い手から引き取らねばならない場合に考えられる不測の事態をカバーするために小売店により「価格保護費用」がしばしば課せられる。更に、小売店は、典型的に、広告チラシでゲームを市場に出す上で助けとなるように発行者に費用を課する。更に、小売店は、ゲームをプレイし終えたユーザからゲームを買い戻して、それを中古ゲームとして販売し、典型的に、中古ゲームの収入をゲーム発行者と分配しないことが増えている。ゲーム発行者に課せられるコスト負担に加えて、しばしばゲームの海賊版が作成されてインターネットを通して配布され、ユーザがそれをダウンロードして無料でコピーする事態になっている。]
[0018] インターネットのブロードバンド速度が高まりつつあり、そして米国内及び世界中で、特に、家庭や、インターネット接続ＰＣがレンタルされるインターネット「カフェー」へのブロードバンド接続がより一般的になってきているので、ゲームは、ＰＣ又はコンソールへのダウンロードを経て益々配布されてきている。又、マルチプレーヤ及び大規模マルチプレーヤのオンラインゲームをプレイするためにブロードバンド接続が益々使用されてきている（それらは、両方とも、本開示では頭文字“ＭＭＯＧ”で参照される）。これらの変更は、小売配布に関連した問題及びコストをある程度軽減する。オンラインゲームをダウンロードすることは、配布コストが典型的に僅かであり且つ売れ残りメディアからのコストがほとんど又は全くないという点で、幾つかの欠点をゲーム発行者に差し向ける。しかし、ダウンロードされたゲームは、依然、海賊行為を受け、そしてそのサイズ（しばしば数ギガバイトのサイズ）のために、ダウンロードするのに非常に長い時間を要する。更に、ポータブルコンピュータ又はビデオゲームコンソールと共に販売されるような小さなディスク装置は複数のゲームで埋め尽くされる。しかしながら、ゲーム又はＭＭＯＧがプレイ可能なゲームのためのオンライン接続を要求する程度まで、海賊版の問題は、軽減されている。というのは、ユーザが、通常、有効なユーザアカウントを有することが要求されるからである。ディスプレイスクリーンのビデオを撮影するカメラ又はスピーカからの音声を録音するマイクロホンによりコピーできるリニアメディア（例えば、ビデオ及び音楽）とは異なり、各ビデオゲームの経験は独特なものであり、簡単なビデオ／オーディオ記録を使用してコピーすることができない。従って、著作権法が強力に施行されておらず、海賊行為が横行する地域でも、ＭＭＯＧは、海賊行為から遮蔽され、それ故、ビジネスをサポートすることができる。例えば、Ｖｉｖｅｎｄｉ ＳＡの“World of Warcraft”ＭＭＯＧは、世界中にわたって海賊行為で悩まされずに首尾良く展開された。そして、多くのオンライン又はＭＭＯＧゲーム、例えば、Ｌｉｎｄｅｎ Ｌａｂの“Second Life”ＭＭＯＧは、オンラインツールを使用して資産を買い、売り、そして形成するゲームに内蔵された経済的モデルを通してゲームのオペレータのための収入を発生する。従って、従来のゲームソフトウェアの購入又は契約に加えて、メカニズムを使用して、オンラインゲームを使用するための支払をすることができる。]
[0019] オンラインの性質又はＭＭＯＧにより海賊行為をしばしば軽減できるが、オンラインゲームオペレータは、依然、残りの挑戦に直面している。多くのゲームは、オンライン又はＭＭＯＧが適切に機能するために実質的なローカル（即ち、家庭内）処理リソースを要求する。ユーザは、性能の低いローカルコンピュータ（例えば、ローエンドラップトップのような、ＧＰＵをもたないもの）を有する場合に、ゲームをプレイできないことがある。更に、ゲームコンソールが古くなるにつれて、最新型から徐々に後退し、より進歩したゲームを取り扱うことができなくなる。ユーザのローカルＰＣがゲームの計算要求を取り扱いできると仮定しても、しばしばインストールの複雑さがある。ドライバの互換性がないことがある（例えば、新たなゲームがダウンロードされる場合に、グラフィックドライバの新たなバージョンがインストールされ、これは、グラフィックドライバの古いバージョンに基づく以前にインストールされたゲームを不作動にすることがある）。コンソールは、より多くのゲームがダウンロードされるにつれて、ローカルディスクスペースを使い果たす。複雑なゲームは、典型的に、バグが見つかって修理されたとき、又はゲームに変更がなされた場合に（例えば、ゲームのレベルがプレイするのに難し過ぎるか又は容易過ぎるとゲーム開発者が分かった場合に）、ゲーム開発者から時間と共にダウンロードされたパッチを受け取る。これらのパッチは、新たなダウンロードを要求する。しかし、時々、全てのユーザが全てのパッチのダウンロードを完了するのではない。他のときには、ダウンロードされたパッチが他の互換性又はディスクスペース消費の問題を導入する。]
[0020] 又、ゲームのプレイ中に、グラフィック又は挙動情報をローカルＰＣ又はコンソールに与えるために大きなデータダウンロードが要求されることがある。例えば、ユーザがＭＭＯＧの部屋に入り、そしてグラフィックデータで作られるか又はユーザのローカルマシンでは得られない挙動をもつシーン又はキャラクタに遭遇する場合には、そのシーン又はキャラクタのデータをダウンロードしなければならない。その結果、インターネット接続が充分に高速でない場合には、ゲームのプレイ中に実質的な遅延を招く。そして、遭遇したシーン又はキャラクタが、ローカルＰＣ又はコンソールを越えるような記憶スペース又は計算能力を要求する場合には、ユーザがゲームを進められないか又は質の低いグラフィックで続けねばならない事態を招く。従って、オンライン又はＭＭＯＧゲームは、それらの記憶及び／又は計算の複雑さの要件をしばしば制限する。更に、それらは、ゲーム中のデータ転送の量をしばしば制限する。又、オンライン又はＭＭＯＧは、ゲームをプレイできるユーザの市場を狭めることもある。]
[0021] 更に、技術的知識のあるユーザがゲームのローカルコピーをリバースエンジニアリングし、そしてチートできるようにゲームを変更することが次第に増えてきている。チートは、人間的に可能である以上に速くボタン押しを繰り返すのと同程度に簡単である（例えば、銃を非常に速く撃つように）。ゲーム内資産トランザクションをサポートするゲームでは、チートが、実際の経済的価値の資産を含む詐欺的トランザクションを生じるレベルの精巧さに到達する。オンライン又はＭＭＯＧ経済的モデルがそのような資産トランザクションに基づくものであるときは、これは、ゲームオペレータに実質的に有害な結果をもたらす。]
[0022] 新たなゲームを開発するコストは、ＰＣ及びコンソールが（例えば、リアルタイムレイトレーシングのようなより現実的なグラフィック、及びリアルタイム物理的シミュレーションのようなより現実的な挙動と共に）益々精巧なゲームを作成できるのにつれて増大している。ビデオゲーム産業の初期には、ビデオゲーム開発は、アプリケーションソフトウェア開発に非常に類似したプロセスであり、即ち開発コストの大部分は、ソフトウェアの開発であり、グラフィック、オーディオ、及び挙動エレメント又は「資産」の開発、例えば、広範囲な特殊効果をもつ動画に対して開発されるものではない。今日、多くの精巧なビデオゲーム開発努力は、ソフトウェア開発よりも、特殊効果に富んだ動画開発に厳密に似ている。例えば、多くのビデオゲームは、３Ｄ世界のシミュレーションを与え、そして益々ホトリアリスティックな（即ち、生きた動きの映像写真撮影と同程度に現実的に見えるコンピュータグラフィックの）キャラクタ、プロップ及び環境を発生する。ホトリアリスティックなゲーム開発の最も挑戦的な観点の１つは、生きた動きの人間の顔と見分けがつかないようなコンピュータ発生の人間の顔を創作することである。カリフォルニア州サンフランシスコのＭｏｖａにより開発されたＣｏｎｔｏｕｒTMリアリティキャプチャーのような顔捕獲技術は、演技者の顔の正確な形状を運動中に高い解像度で捕獲し追跡する。この技術は、捕獲された生きた動きの顔と実質上区別できない３Ｄの顔をＰＣ又はゲームコンソール上にレンダリングできるようにする。「ホトリアル」な人間の顔を捕獲してレンダリングすることは、多数の観点で有用である。第１に、非常に認識し易い有名人又はスポーツプレーヤ（多くの場合に高い費用で雇われた）がビデオゲームにしばしば使用され、不完全さがユーザにとって明らかで、視覚体験(viewing experience)を混乱させ又は不快にさせることがある。又、多くの場合に、高度のホトリアリズムを達成するには高度の細部が要求され、即ち、潜在的に、顔が動くときに多角形及び／又はテクスチャがフレームごとに変化するようにして、多数の多角形及び高解像度テクスチャをレンダリングすることが要求される。]
[0023] 詳細なテクスチャを伴う多数の多角形のシーンが急速に変化するときには、ゲームをサポートするＰＣ又はゲームコンソールは、ゲームセグメントで発生される所要数のアニメーションフレームに対して充分な多角形及びテクスチャデータを記憶するに足るＲＡＭを有していないことがある。更に、ＰＣ又はコンソールに典型的に利用できる単一の光学的ドライブ又は単一のディスクドライブは、通常、ＲＡＭより非常に低速であり、そして典型的に、多角形及びテクスチャをレンダリングする際にＧＰＵが受け容れられる最大データレートを維持することができない。現在のゲームは、典型的に、多角形及びテクスチャの大部分をＲＡＭにロードし、これは、所与のシーンの複雑さ及び時間巾が主としてＲＡＭの容量により制限されることを意味する。例えば、顔のアニメーションの場合に、これは、ゲームが休止して多角形及びテクスチャ（及び他のデータ）をより多くのフレームに対してロードする前に、ＰＣ又はゲームコンソールを、ホトリアルでない低解像度の顔、又は限定された数のフレームについてのみアニメ化できるホトリアルな顔、のいずれかに制限する。]
[0024] “Loading...”に類似したメッセージをＰＣ又はコンソールが表示するときに進行バーがスクリーンを横切ってゆっくり移動するのを見ていることは、複雑なビデオゲームの今日のユーザによって固有の欠点として容認されている。次のシーンがディスク（ここで、「ディスク」とは、特に指示のない限り、不揮発性の光学又は磁気メディア、並びに非ディスクメディア、例えば、半導体「フラッシュ」メモリを指す）からロードする間の遅延は、数秒又は数分を要する。これは、時間の浪費であり、ゲームプレーヤにとってかなりのフラストレーションとなる。上述したように、多くの又は全ての遅延は、多角形、テクスチャ又は他のデータをディスクからロードする時間によるものであるが、ＰＣ又はコンソール内のプロセッサ及び／又はＧＰＵがシーンのためのデータを準備する間にロード時間の一部分が費やされる場合もある。例えば、サッカービデオゲームは、プレーヤが、多数の選手、チーム、スタジアム及び天候条件の中から選択を行えるようにする。従って、どんな特定の組合せが選択されるかに基づいて、異なる多角形、テクスチャ及び他のデータ（集合的に「オブジェクト」）がシーンに対して要求される（例えば、異なるチームは、そのユニホームに異なるカラー及びパターンを有する）。多数の又は全ての種々の順列を列挙し、多数の又は全てのオブジェクトを前もって予め計算し、そしてそれらオブジェクトを、ゲームを記憶するのに使用されるディスクに記憶することができる。しかし、順列の数が多い場合には、全オブジェクトに対して要求される記憶の量が、ディスクに適合するには大き過ぎる（ダウンロードするには不可能である）ことがある。従って、既存のＰＣ及びコンソールシステムは、典型的に、所与のシーンの複雑さ及びプレイ時間巾の両方について制約があり、複雑なシーンに対する長いロード時間で悩まされている。]
[0025] 従来のビデオゲームシステム及びアプリケーションソフトウェアシステムに伴う別の顕著な制限は、それらが、例えば、ＰＣ又はゲームコンソールへ処理のためにロードされる必要のある多角形及びテクスチャのような３Ｄオブジェクトの大きなデータベースを次第に使用してきていることである。上述したように、このようなデータベースは、ディスクにローカルに記憶されるときに長いロード時間を要する。しかしながら、ロード時間は、通常、データベースがリモート位置に記憶されそしてインターネットを通してアクセスされる場合には更に厳しいものとなる。このような状態では、大きなデータベースをダウンロードするのに、数分、数時間、又は数日を要することがある。更に、このようなデータベースは、多くの場合に多大な費用で生成され（例えば、ゲーム、映画又は歴史ドキュメンタリーに使用するための詳細な高いマスト付きの帆船の３Ｄモデル）、そしてローカルエンドユーザに販売するように意図される。しかしながら、データベースは、ローカルユーザへダウンロードされると、海賊行為を受けるおそれがある。多くの場合、ユーザは、データベースを評価してそれがユーザのニーズに合うか（例えば、ユーザが特定の動きをするときにゲームキャラクタの３Ｄコスチュームが満足な見掛け又は外観を有するか）どうか調べるだけのためにデータベースのダウンロードを希望する。長いロード時間は、購入することを決断する前に３Ｄデータベースを評価するユーザにとって妨げになる。]
[0026] ＭＭＯＧでは、特に、ユーザがカスタマイズされたキャラクタを次第に使用できるようなゲームとして、同様の問題が発生する。キャラクタを表示するためのＰＣ又はゲームコンソールの場合に、３Ｄ幾何学（多角形、テクスチャ、等）のデータベースへのアクセス及びそのキャラクタに対する挙動（例えば、キャラクタが盾を有する場合に、その盾が槍をそらすに充分な強度であるかどうか）を得ることが必要である。典型的に、ＭＭＯＧがユーザにより最初にプレイされるときには、キャラクタに対する多数のデータベースが、ゲームの初期コピーと共に予め入手でき、これは、ゲームの光学的ディスクにローカルで入手できるか又はディスクへダウンロードされる。しかし、ゲームが進行するにつれて、データベースがローカルで入手できないキャラクタ又はオブジェクトにユーザが遭遇する場合には（例えば、別のユーザがカスタマイズされたキャラクタを生成した場合には）、そのキャラクタ又はオブジェクトを表示できるまでに、そのデータベースがダウンロードされねばならない。これは、ゲームの実質的な遅延を生じさせる。]
[0027] ビデオゲームの精巧さ及び複雑さがあるとすれば、従来のビデオゲームコンソールでのビデオゲーム開発者及び発行者の別の挑戦は、多くの場合、数千万ドルのコストで２ないし３年を掛けてビデオゲームを開発することである。新規なビデオゲームコンソールプラットホームがほぼ５年毎に一度の割合で導入されると仮定すれば、ゲーム開発者は、新規なプラットホームが発売されるのと同時にビデオゲームを入手できるようにするために、新規なゲームコンソールの発売よりこれらゲーム年だけ前に開発作業をスタートする必要がある。ほぼ同じ時期に（例えば、互いに１年又は２年以内に）競合する製造者から多数のコンソールが時々発売されるが、調べなければならないものは、各コンソールの人気であり、例えば、どのコンソールがビデオゲームソフトウェアの最大売り上げを生じるかである。例えば、近年のコンソールサイクルでは、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ３６０、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３及びＮｉｎｔｅｎｄｏ Ｗｉｉがほぼ同じ一般的な時間枠で導入されるようにスケジュールされている。しかし、導入の何年か前に、ゲーム開発者は、どのコンソールプラットホームが他のものより成功するか本質的に「賭け」をし、それに応じて、開発リソースを捧げなければならない。又、動画制作会社も、映画の封切りの充分前に映画の成功の見込みの推定に基づいて限られた制作リソースを配分しなければならない。ビデオゲームに要求される投資レベルの増大を仮定すれば、ゲーム制作は、動画制作と益々類似してきており、ゲーム制作会社は、特定のビデオゲームの将来の成功の推定に基づいて制作リソースを日常的に捧げる。しかし、動画会社とは異なり、この賭けは、単に制作それ自体の成功に基づくものではなく、むしろ、ゲームの実行が意図されたゲームコンソールの成功に基づいたものである。複数のコンソールに対するゲームを一度に発売することでリスクを軽減できるが、この付加的な努力がコストを増大し、ゲームの実際の発売をしばしば遅らせる。]
[0028] ＰＣにおけるアプリケーションソフトウェア及びユーザ環境は、ユーザに対してより視覚的に訴えるだけでなく、より有効で且つ直感的なものにするために、計算上より集中的で、動的で且つ双方向のものとなる。例えば、新規なＷｉｎｄｏｗｓ ＶｉｓｔａTMオペレーティングシステム、及びＭａｃｉｎｔｏｓｈ（登録商標）オペレーティングシステムの次々のバージョンは、視覚アニメーション効果を合体している。Ａｕｔｏｄｅｓｋ社からのＭａｙａTMのような進歩型グラフィックツールは、最新のＣＰＵ及びＧＰＵの限界を押し進める非常に精巧な３Ｄレンダリング及びアニメーション能力を与える。しかしながら、これら新規なツールの計算上の要件は、そのような製品のユーザ及びソフトウェア開発者にとって多数の実際上の問題を生じさせる。]
[0029] オペレーティングシステム（ＯＳ）の視覚表示は、もはや販売されていないが新規なＯＳで依然アップグレード可能である前世代のコンピュータを含めて、広範囲な種類のコンピュータにおいて機能しなければならないので、ＯＳグラフィック要件は、典型的にＧＰＵを含まないコンピュータを含めたＯＳのターゲットであるコンピュータの最小公分母によって大きく制限される。これは、ＯＳのグラフィック能力を甚だしく制限する。更に、バッテリ作動式のポータブルコンピュータ（例えば、ラップトップ）は、視覚表示能力を制限する。というのは、ＣＰＵ又はＧＰＵにおける高い計算上のアクティビティが、典型的に、電力消費を高め、バッテリ寿命を短くするからである。ポータブルコンピュータは、典型的に、プロセッサが利用されないときに消費電力を下げるためにプロセッサのアクティビティを自動的に下げるソフトウェアを含む。あるコンピュータモデルでは、ユーザは、プロセッサのアクティビティを手動で下げることができる。例えば、ソニーのＶＧＮ−ＳＺ２８０Ｐラップトップは、（低性能、長バッテリ寿命のために）片側に“Ｓｔａｍｉｎａ”と表示され且つ（高性能、短バッテリ寿命のために）他側に“Ｓｐｅｅｄ”と表示されたスイッチを含む。ポータブルコンピュータで実行されるＯＳは、コンピュータがそのピーク性能能力の一部分で実行される場合でも、有用に機能することができねばならない。従って、ＯＳグラフィック性能は、入手可能な最新の計算能力より遥かに下に留まることがしばしばある。]
[0030] Ｍａｙａのようなハイエンドの計算に強いアプリケーションは、高性能ＰＣに使用されるという期待でしばしば販売される。これは、典型的に、非常に高い性能と、より高価で且つ低ポータブル性の最小公分母要求を確立する。その結果、このようなアプリケーションは、汎用のＯＳ（又はＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅのような汎用の生産アプリケーション）より非常に限定されたターゲット視聴者を有し、典型的に、汎用のＯＳソフトウェア又は汎用のアプリケーションソフトウェアより相当に少ない量で販売される。又、多くの場合、見込みのあるユーザがこのような計算に強いアプリケーションを前もって試すことは困難であるから、潜在的な視聴者は更に限定される。例えば、学生がＭａｙａの使い方を学習することを希望し、又はこのようなアプリケーションについて既に知識のある潜在的な買い手が購入（Ｍａｙａを実行できるハイエンドコンピュータを買うことも含む）に投資する前にＭａｙａを試すことを希望すると仮定する。学生又は潜在的な買い手は、Ｍａｙａのデモバージョンをダウンロードするか又はその物理的メディアコピーを得ることはできるが、Ｍａｙａをそのフル能力（例えば、複雑な３Ｄシーンを取り扱う）で実行できるコンピュータがない場合には、製品の完全なインフォームドアセスメントを行うことができない。これは、このようなハイエンドアプリケーションの視聴者を制限するものである。又、これは、高い販売価格にも貢献する。というのは、開発コストは、通常、汎用アプリケーションより非常に少数の購入にわたって割賦されるからである。]
[0031] 又、高価格アプリケーションは、個人や企業がアプリケーションソフトウェアの海賊版コピーを使用する大きな誘因も生み出す。その結果、ハイエンドのアプリケーションソフトウェアは、種々の技術を通して海賊行為を軽減するためにそのようなソフトウェアの発行者による顕著な努力にも関わらず、海賊版がはびこることで悩まされている。海賊版のハイエンドのアプリケーションを使用するときでも、ユーザは、海賊版コピーを実行するために高価な最新のＰＣに投資する必要性を排除することはできない。従って、海賊版ソフトウェアのユーザは、その実際の小売価格の一部分でソフトウェアアプリケーションを使用できるが、そのアプリケーションをフルに利用するためには、高価なＰＣを購入又は入手することが依然要求される。]
[0032] 高性能の海賊版ビデオゲームのユーザについても同じことが言える。海賊行為者は、ゲームをそれらの実際の価格の一部分で得ることはできるが、ゲームを適切にプレイするのに必要な高価なコンピューティングハードウェア（例えば、ＧＰＵ増強型ＰＣ、又はＸＢｏｘ３６０のようなハイエンドのビデオゲームコンソール）を購入することが依然要求される。ビデオゲームが典型的に消費者にとって気晴らしであると仮定すれば、ハイエンドのビデオゲームシステムのための付加的なコストが法外なものとなる。この事態は、現在の労働者の平均年収が米国に比してかなり低い国（例えば、中国）では、一層悪いものである。その結果、ハイエンドのビデオゲームシステム又はハイエンドのＰＣを所有するのは、人口の非常に僅かな割合だけとなる。このような国々では、インターネットに接続されたコンピュータを使用するための料金をユーザが支払う「インターネットカフェ」が極めて一般的となる。多くの場合に、このようなインターネットカフェは、プレーヤが計算に強いビデオゲームをプレイできるようにするＧＰＵのような高性能特徴をもたない旧モデル又はローエンドＰＣしか有していない。これは、中国で非常に成功し、そこのインターネットカフェで一般にプレイされるＶｉｖｅｎｄｉの“World of Warcraft”のような、ローエンドＰＣで実行されるゲームの成功における重要なファクタである。それと対照的に、“Second Life”のような計算に強いゲームは、中国のインターネットカフェにインストールされたＰＣでプレイできる見込みが極めて低い。このようなゲームは、インターネットカフェの低性能ＰＣにしかアクセスできないユーザには、実質上アクセス不能である。]
[0033] 又、ビデオゲームの購入を考えており、先ず、インターネットを経て自分の家にゲームのデモバージョンをダウンロードすることによりそれを試してみたいユーザにとってもバリアが存在する。ビデオゲームのデモは、多くの場合、幾つかの特徴がディスエイブルされるか又はゲームのプレイ量に限度が課せられたゲームの一人前のバージョンである。これは、ＰＣ又はコンソールのいずれかにゲームをインストールして実行できるまでにギガバイトのゲームをダウンロードする長いプロセス（おそらく数時間）を伴うことがある。ＰＣの場合には、ゲームに対して必要とされる特殊なドライバ（例えば、ＤｉｒｅｃｔＸ又はＯｐｅｎＧＬドライバ）を計算し、正しいバージョンをダウンロードして、それらをインストールし、次いで、ＰＣがゲームをプレイできるかどうか決定することを含む。この後者のステップは、ＰＣが充分な処理（ＣＰＵ及びＧＰＵ）能力、充分なＲＡＭ、及び互換性のあるＯＳ（例えば、あるゲームは、Ｗｉｎｄｏｗｓ ＸＰで実行されるが、Ｖｉｓｔａでは実行されない）を有するかどうか決定することを含む。従って、ビデオゲームデモを実行するよう試みる長いプロセスの後に、ユーザは、ユーザのＰＣコンフィギュレーションを仮定すれば、ビデオゲームデモがおそらくプレイできないことを充分見出すことができる。悪いことに、ユーザが、デモを試すために新規なドライバダウンロードすると、それらのドライババージョンは、ユーザがＰＣにおいて普通に使用している他のゲーム又はアプリケーションとの互換性がないことがあり、従って、デモをインストールすると、以前に動作できたゲーム又はアプリケーションが不作動になることがある。これらのバリアは、ユーザにフラストレーションを与えるだけでなく、ゲームを市場に出すビデオゲームソフトウェア発行者及びビデオゲーム開発者にとってもバリアとなる。]
[0034] 経済的な非効率さを招く別の問題は、所与のＰＣ又はゲームコンソールが、通常、アプリケーション及び／又はゲームに対するあるレベルの性能要件を受け容れるように設計されていることに関する。例えば、あるＰＣは、多少のＲＡＭを有し、低速又は高速のＣＰＵを有し、そしてＧＰＵを有する場合には低速又は高速のＧＰＵを有する。あるゲーム又はアプリケーションは、所与のＰＣ又はコンソールの全計算パワーの利点を取り入れるが、多くのゲーム又はアプリケーションは、そうではない。ゲーム又はアプリケーションについてのユーザの選択が、ローカルＰＣ又はコンソールのピーク性能能力に達しない場合には、ユーザは、利用されない特徴に関してＰＣ又はコンソール上で金銭を浪費することになる。コンソールの場合には、コンソールの製造者は、コンソールコストを助成するために必要であった以上に支払ったことになる。]
[0035] ビデオゲームを買って楽しむ際に存在する別の問題は、ユーザがゲームの購入を決める前に他の者がそのゲームをプレイしているのをユーザが見ることができるようにすることに関する。ビデオゲームを記録して後で再生するための多数の従来の解決策が存在する。例えば、米国特許第５，５５８，３３９号は、（同じユーザ又は異なるユーザにより所有された）ビデオゲームクライアントコンピュータでの「ゲームプレイ」中にゲームコントローラのアクションを含むゲーム情報体情報を記録することを教示している。この状態情報を後で使用して、ビデオゲームクライアントコンピュータ（例えば、ＰＣ又はコンソール）上で幾つか又は全てのゲームアクションを再生することができる。この解決策の顕著な欠点は、ユーザが記録されたゲームを見るために、ユーザは、ゲームをプレイできるビデオゲームクライアントコンピュータを所有すると共に、記録されたゲーム状態が再生されたときにゲームプレイが同一となるようにそのコンピュータ上で実行されるビデオゲームアプリケーションを有していなければならないことである。この他に、ビデオゲームアプリケーションは、記録されたゲームと再生されるゲームとの間に実行の相違がないように書かれねばならない。]
[0036] 例えば、ゲームグラフィックは、一般的に、フレームごとに計算される。多くのゲームの場合に、ゲームロジックは、時々、シーンが特に複雑であるかどうか、又は実行速度を下げる他の遅延があるかどうか（例えば、ＰＣにおいて、ゲームアプリケーションからＣＰＵサイクルを取り去る別のプロセスが実行されるかどうか）に基づいて、次のフレームに対して表示されるグラフィックを計算するのに１フレームより短い又は長い時間を要する。このようなゲームでは、１フレーム時間より若干短く（例えば、数ＣＰＵクロックサイクル短く）計算された「スレッシュホールド」フレームが最終的に発生する。その同じシーンが、全く同じゲーム状態情報を使用して再び計算されたときには、１フレーム時間より数ＣＰＵクロックサイクル長くかかることが容易に起きる（例えば、内部ＣＰＵバスが外部ＤＲＡＭバスと若干位相ずれし、そしてゲーム処理から数ミリ秒のＣＰＵ時間を取り去る別のプロセスによる大きな遅延がなくても、数ＣＰＵサイクルの時間遅延を導入する場合には）。それ故、ゲームが再生されるときには、フレームは、１つのフレーム時間ではなく、２つのフレーム時間で計算される。幾つかの挙動は、ゲームがどれほど頻繁に新たなフレームを計算するか（例えば、いつゲームがゲームコントローラから入力をサンプルするか）に基づいている。ゲームが表示されている間には、異なる挙動に対する時間基準のこの相違は、ゲームのプレイに影響しないが、再生されたゲームが異なる結果を生じさせることを招く。例えば、バスケットボールの弾道は、一定の６０ｆｐｓ速度で計算されるが、ゲームコントローラの入力が、計算されたフレームの速度に基づいてサンプリングされる場合には、計算されたフレームの速度は、ゲームが記録されたときは５３ｆｐｓであるが、ゲームが再生されるときは５２ｆｐｓとなり、これは、バスケットボールがバスケットへ入ることが阻止されるかどうかに差を生じさせ、異なる結果を招くことになる。従って、ゲーム状態を使用してビデオゲームを記録するには、同じゲーム状態情報を使用した再生が全く同じ結果を生じさせるよう保証するために非常に入念なゲームソフトウェア設計が要求される。]
[0037] ビデオゲームを記録するための別の従来の解決策は、ＰＣ又はビデオゲームシステムのビデオ出力を（例えば、ＶＣＲ、ＤＶＤレコーダへ、又はＰＣ上のビデオ捕獲ボードへ）単に記録することである。次いで、ビデオは、巻き戻して再生することもできるし、或いは記録されたビデオを、典型的に、圧縮した後にインターネットへアップロードすることもできる。この解決策の欠点は、３Ｄゲームシーケンスが再生されるときに、ユーザは、シーケンスが記録された視点のみからシーケンスを見ることに限定されることである。換言すれば、ユーザは、シーンの視点を変更することができない。]
[0038] 更に、家庭用ＰＣ又はゲームコンソールで再生される記録されたゲームシーケンスの圧縮ビデオがインターネットを通して他のユーザに利用されるときには、ビデオがリアルタイムで圧縮された場合でも、その圧縮されたビデオをリアルタイムでインターネットにアップロードすることは不可能である。その理由は、インターネットに接続された世界中の多数の家庭が、極めて非対称的なブロードバンド接続を有する（例えば、ＤＳＬ及びケーブルモデムは、典型的に、アップストリーム帯域巾よりも遥かに広いダウンストリーム帯域巾を有する）からである。圧縮された高解像度ビデオシーケンスは、多くの場合に、ネットワークのアップストリーム帯域巾容量より広い帯域巾を有し、それらをリアルタイムでアップロードするのを不可能にする。従って、ゲームシーケンスが再生された後、インターネットの別のユーザがゲームを見ることができるまでに著しい遅延が生じる（おそらく数分又は数時間）。この遅延は、ある状況（例えば、以前に生じたゲームプレーヤの成績を見る）では許容できるが、ゲーム（例えば、チャンピオンプレーヤによりプレイされるバスケットボールトーナメント）を生で見る能力、又はゲームが生でプレイされるときの「瞬時再生」能力を排除する。]
[0039] 別の従来の解決策は、テレビジョン制作員の管理下でのみ、視聴者が、テレビ受像機でビデオゲームを生で見ることができるようにする。米国及び他の国々における幾つかのチャンネルは、ビデオゲーム視聴チャンネルを提供し、テレビ視聴者は、ビデオゲームチャンネル上で何人かのビデオゲームユーザ（例えば、トーナメントでプレイする最高評価プレーヤ）を見ることができる。これは、テレビジョンチャンネル用のビデオ配信及び処理装置へビデオゲームシステム（ＰＣ及び／又はコンソール）のビデオ出力をフィードすることにより達成される。これは、多数のカメラがバスケットボールコートの周囲で異なるアングルから生映像を送る生のバスケットボールゲームをテレビチャンネルが放送するときとは異なる。従って、テレビチャンネルは、それらのビデオ／オーディオ処理を活用して、種々のビデオゲームシステムからの出力を操作するように装置に作用することができる。例えば、テレビチャンネルは、異なるプレーヤの状態を示すテキストをビデオゲームからのビデオの上に重畳することができ（生のバスケットボールゲーム中のオーバーレイテキストであるかのように）、そしてテレビチャンネルは、ゲーム中に生じるアクションについて論じることのできるコメンテータからの音声をかぶせて録音することができる。更に、ビデオゲーム出力を、ゲームの実際のプレーヤのビデオを記録するカメラと合成することができる（例えば、ゲームに対する感情的応答を示す）。]
[0040] この解決策に伴う１つの問題は、生放送の興奮を得るために、このような生のビデオフィードがテレビチャンネルのビデオ配信及び処理装置にリアルタイムで得られねばならないことである。しかしながら、上述したように、これは、ビデオゲームシステムが家庭から実行されるとき、特に、放送の一部分が、ゲームプレーヤの実世界ビデオを捕獲するカメラからの生ビデオを含む場合には、しばしば不可能である。更に、トーナメント状態において、上述したように、家庭内のゲーム遊技者がゲームを変更し及びチートする問題もある。これらの理由で、テレビチャンネルを経てのこのようなビデオゲーム放送は、プレーヤ及びビデオゲームシステムが共通の位置（例えば、テレビスタジオ又は競技場）に集合し、そこで、テレビ制作装置が多数のビデオゲームシステム及び潜在的な生カメラからのビデオフィードを受け容れることができるように、しばしば構成される。]
[0041] このような従来のビデオゲームテレビチャンネルは、ビデオゲームの世界におけるアクション及び実世界におけるアクションの両方に関して、例えば、ビデオゲームプレーヤが「アスリート」として描かれるようにして、生のスポーツイベントに類似した体験である非常に興奮させる上映をテレビの視聴者に与えることができるが、これらのビデオゲームシステムは、プレーヤが互いに物理的に非常に接近した状態にしばしば限定される。そして、テレビチャンネルが放送されて以来、各放送チャンネルは、テレビチャンネルの制作員により選択された１つのビデオストリームしか示すことができない。これらの制限や、放送時間、制作装置及び制作員の高いコストのために、テレビチャンネルは、典型的に、トップトーナメントでプレイする最高評価プレーヤしか示さない。]
[0042] 更に、ビデオゲームのフルスクリーン映像を全テレビ視聴者に放送する所与のテレビチャンネルは、一度に１つのビデオゲームしか示さない。これは、テレビ視聴者の選択肢を甚だしく制限する。例えば、テレビ視聴者は、所与の時間に映されるゲームに関心がないことがある。別の視聴者は、所与の時間にテレビチャンネルによって特集されない特定のプレーヤのゲームプレイを見ることにしか関心がない。他のケースでは、視聴者は、専門プレーヤがゲームにおける特定のレベルをどのように取り扱うか見ることにしか関心がない。更に他の視聴者は、制作チーム等により選択されたものとは異なる、ビデオゲームを見る視点をコントロールすることを希望する。手短に言えば、テレビ視聴者は、多数の異なるテレビチャンネルが見られる場合でも、テレビネットワークの特定の放送によって受け容れられないビデオゲームを見ることに無数の好みをもっている。上述した全ての理由で、従来のビデオゲームテレビチャンネルは、テレビ視聴者にビデオゲームを示す上で著しい制限がある。]
[0043] 従来のビデオゲームシステム及びアプリケーションソフトウェアシステムの別の欠点は、それらが複雑であり、且つエラー、クラッシュ及び／又は意図されない及び望ましからぬ挙動（集合的に「バグ」）により通常悩まされていることである。ゲーム及びアプリケーションは、典型的に、発売までにデバッグ及びチューニングプロセス（しばしば「ソフトウェアクオリティアシュアランス」又はＳＱＡと称される）に通されるが、ほぼ常に、ゲーム又はアプリケーションがその分野の広範囲な視聴者に発売されると、バグが突然現れる。不都合なことに、ソフトウェア開発者は、発売後に多くのバグを識別して追跡することは困難である。ソフトウェア開発者がバグに気付くことは困難である。バグについて学習したときでも、何がバグを生じさせたか識別するために利用できる情報は、限られた量しかない。例えば、ユーザは、ゲーム開発者の顧客サービスラインに電話し、ゲームをプレイするときに、スクリーンがフラッシュを開始し、次いで、濃い青色に変化し、ＰＣがフリーズすることを示すメッセージを残す。これは、ＳＱＡチームに、バグを追跡するのに有用な非常に僅かな情報しか与えない。オンライン接続されたあるゲーム又はアプリケーションは、時々、幾つかのケースでは、多くの情報を与えることができる。例えば、ゲーム又はアプリケーションを「クラッシュ」について監視するために、時々「ウオッチドッグ」プロセスを使用することができる。ウオッチドッグプロセスは、ゲーム又はアプリケーションプロセスがクラッシュしたときにその状態（例えば、スタックの状態、メモリ使用状態、ゲーム又はアプリケーションがどれほど進行したか、等）に関する統計情報を収集し、次いで、その情報を、インターネットを経てＳＱＡチームへアップロードすることができる。しかし、複雑なゲーム又はアプリケーションでは、このような情報は、クラッシュ時にユーザが何を行ったか正確に決定するために解読するのに非常に長時間を要する。従って、どんな事象シーケンスがクラッシュを招いたか決定することが不可能である。]
[0044] ＰＣ及びゲームコンソールに関連した更に別の問題は、消費者に相当不便をかけるサービスの問題を受けることである。又、これらサービスの問題は、ＰＣ又はゲームコンソールの製造者に影響を及ぼす。というのは、製造者は、壊れたＰＣ又はコンソールを安全に運搬するために特殊なボックスを送付し、ＰＣ又はコンソールが保証期間内である場合には修理のコストを負う必要があるからである。又、ゲーム又はアプリケーションソフトウェアの発行者は、ＰＣ及び／又はコンソールが修理の状態にあることによる販売の損失（又はオンラインサービス使用）によっても影響を受ける。]
[0045] 図１は、Ｓｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ（登録商標）３、Ｍｉｃｒｏｓｏｆｔ ＸＢｏｘ ３６０（登録商標）、Ｎｉｎｔｅｎｄｏ ＷｉｉTM、Ｗｉｎｄｏｗベースのパーソナルコンピュータ、又はＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈのような従来のビデオゲームシステムを示す。これらシステムは、各々、プログラムコードを実行するための中央処理ユニット（ＣＰＵ）、典型的に、進歩型グラフィックオペレーションを遂行するためのグラフィック処理ユニット（ＧＰＵ）、並びに外部装置及びユーザと通信するための複数の形態の入力／出力（Ｉ／Ｏ）を備えている。簡単化のために、これらのコンポーネントは、単一のユニット１００として一緒に結合されて示されている。又、図１の従来のビデオゲームシステムは、光学的メディアドライブ１０４（例えば、ＤＶＤ−ＲＯＭドライブ）、ビデオゲームのプログラムコード及びデータを記憶するためのハードドライブ１０３、マルチプレーヤゲームをプレイし、ゲーム、パッチ、デモ又は他のメディアをダウンロードするためのネットワーク接続１０５、ＣＰＵ／ＧＰＵ１００により現在実行されているプログラムコードを記憶するためのランダムアクセスメモリ（ＲＡＭ）１０１、ゲームプレイ中にユーザからの入力コマンドを受け取るためのゲームコントローラ１０６、及びディスプレイ装置１０２（例えば、ＳＤＴＶ／ＨＤＴＶ又はコンピュータモニタ）を含むように示されている。] 図１
[0046] 図１に示す従来のシステムは、多数の制限で悩まされている。第１に、光学的ドライブ１０４及びハードドライブ１０３は、ＲＡＭ１０１に比して非常に低速のアクセス速度を有する傾向がある。ＲＡＭ１０１を通して直接機能するときには、ＣＰＵ／ＧＰＵ１００は、実際に、プログラムコード及びデータがハードドライブ１０３又は光学ドライブ１０４から直接読み取られるときに可能であるより遥かに多くの多角形を毎秒処理することができる。というのは、ＲＡＭ１０１は、一般的に、帯域巾が非常に広く、ディスクメカニズムの比較的長いシーク遅延で悩まされないからである。しかし、これら従来システムでは、限定された量のＲＡＭしか設けられていない（例えば、２５６−５１２Ｍバイト）。それ故、ビデオゲームの次のシーケンスのためのデータでＲＡＭ１０１が周期的に埋められる“Ｌｏａｄｉｎｇ．．．”シーケンスがしばしば要求される。] 図１
[0047] あるシステムは、ゲームプレイと同時にプログラムコードのローディングを重畳させるように試みているが、これは、既知の事象シーケンスがあるときしか行うことができない（例えば、車を運転して道路を下る場合に、車を運転しながら、路傍にある接近してくるビルの幾何学形状をロードすることができる）。複雑で及び／又は急速なシーンの変化については、この形式の重畳は、通常、機能しない。例えば、ユーザが戦いの最中であり、そしてその瞬間に視野内のオブジェクトを表すデータでＲＡＭ１０１が完全に埋められるケースでは、ＲＡＭ１０１に現在ロードされていないオブジェクトを見るためにユーザが視野を素早く左へ動かした場合に、アクションの不連続状態が生じる。というのは、ハードドライブ１０３又は光学的メディア１０４から新たなオブジェクトをＲＡＭ１０１へロードするに充分な時間がないからである。]
[0048] 図１のシステムでは、ハードドライブ１０３及び光学的メディア１０４の記憶容量に制限があるために別の問題が生じる。比較的大きな記憶容量（例えば、５０ギガバイト以上）をもつディスク記憶装置を製造することはできるが、現在ビデオゲームで遭遇する幾つかのシーンについて充分な記憶容量をまだ与えることができない。例えば、上述したように、サッカーのビデオゲームは、世界中の多数のチーム、プレーヤ及びスタジアムの中からユーザが選択を行えるようにする。各チーム、各プレーヤ及び各スタジアムに対して、世界中の３Ｄ曲面を特徴付けるには非常に多数のテクスチャマップ及び環境マップが要求される（例えば、各チームが独特のジャージを有し、その各々が独特のテクスチャマップを要求する）。] 図１
[0049] この後者の問題に対処するために使用される１つの技術は、ユーザによってテクスチャ及び環境マップが選択されたときにゲームがそれらを予め計算することである。これは、映像の解凍、３Ｄマッピング、シェーディング、データ構造の編成、等を含めて、多数の計算上強いプロセスを含むことがある。その結果、ビデオゲームがこれらの計算を遂行する間にユーザにとって遅延が生じ得る。この遅延を減少するための１つの方法は、原理的に、ゲームが最初に開発されたときに、チーム、プレーヤ名簿及びスタジアムの各順列を含めて、これら計算の全てを遂行することである。従って、ゲームの発売バージョンは、光学的メディア１０４、又はインターネット上の１つ以上のサーバーに記憶された全てのこの前処理されたデータを、ユーザが選択を行うときにインターネットを通してハードドライブ１０３へダウンロードされる所与のチーム、プレーヤ名簿、スタジアム選択のための選択された前処理されたデータと共に含む。しかしながら、実際上の問題として、ゲームプレイにおいて考えられる各順列のこのような予めロードされるデータは、多分、今日の光学的メディア装置の容量を遥かに越えるテラバイトのデータになってしまう。更に、所与のチーム、プレーヤ名簿、スタジアム選択のためのデータは、多分、数百メガバイト以上のデータになってしまう。例えば、１０Ｍｂｐｓの家庭用ネットワーク接続では、ネットワーク接続１０５を通してこのデータをダウンロードするのに、データをローカルで計算する以上の時間を要することになる。]
[0050] 従って、図１に示す従来のゲームアーキテクチャーは、複雑なゲームの主要シーン移行間にユーザに著しい遅延を受けさせる。] 図１
[0051] 図１に示す従来の解決策に伴う別の問題は、年々、ビデオゲームがより進歩する傾向にあり、より高いＣＰＵ／ＧＰＵパワーを要求することである。従って、限定された量のＲＡＭを仮定しても、ビデオゲームハードウェアの要件は、これらシステムに得られる処理パワーのピークレベルを越えてしまう。その結果、ユーザは、歩調を合わせるためにゲームハードウェアを数年毎にアップグレードする必要がある（又は新たなゲームを質の低いレベルでプレイする）。ビデオゲームが絶えず進歩する傾向の１つの結果として、家庭で使用するためのビデオゲームプレイマシンは、典型的に、それらのコストが、通常、サポートできる最高性能ゲームの要件により決定されるので、経済的に効率が悪い。例えば、ＸＢｏｘ ３６０は、高性能ＣＰＵ、ＧＰＵ、及び数百メガバイトのＲＡＭを必要とする“Gears of War”のようなゲームをプレイするのに使用されるか、又はＸＢｏｘ ３６０は、数キロバイトのＲＡＭ及び非常に低性能のＣＰＵしか要求しない１９７０年代のゲームであるＰａｃ Ｍａｎをプレイするのに使用される。実際に、ＸＢｏｘ ３６０は、Ｐａｃ Ｍａｎゲームを一度に多数同時にホストするに充分な計算パワーを有している。] 図１
[0052] ビデオゲームマシンは、典型的に、一週間のほとんどの時間中オフにされている。１３年以上経った現役ゲームに関するニールセン・エンターテーメント・スタディ２００６年７月号によれば、平均で、現役のゲームは、毎週１４時間をコンソールビデオゲームのプレイに費やしており、即ち一週間の合計時間の１２％に過ぎない。これは、平均でビデオゲームコンソールが８８％の時間アイドル状態であり、高価なリソースの使用効率が悪いことを意味する。購入価格を下げるためにビデオゲームコンソールが製造者によりしばしば助成されると仮定すれば（その助成金が将来のビデオゲームソフトウェアの購入からのロイヤリティにより還元されることを期待して）、これは、特に意義深いことである。]
[0053] 又、ビデオゲームコンソールは、ほとんどの消費者電子装置に関連したコストを負っている。例えば、システムの電子装置及びメカニズムは、エンクロージャ内に収容する必要がある。製造者は、修理保証を提供する必要がある。システムを販売する小売店は、システムの販売及び／又はビデオゲームソフトウェアの販売において利ざやを収集する必要がある。これらのファクタは、全てビデオゲームコンソールのコストに追加され、これは、製造者によって助成されねばならないか、消費者へ回されるか、又はその両方である。]
[0054] 更に、ビデオゲーム産業にとって海賊版が主たる問題である。実質上全ての主要ビデオゲームシステムに使用されるセキュリティメカニズムは、年々「クラック」されて、ビデオゲームの無断コピーが取られている。例えば、ＸＢｏｘ ３６０のセキュリティシステムは、２００６年７月にクラックされ、ユーザは、今や、不正コピーをオンラインでダウンロードすることができる。ダウンロード可能なゲーム（例えば、ＰＣ又はＭａｃ用のゲーム）は、特に海賊行為を受け易い。海賊行為の取り締まりが弱い世界のある地域では、スタンドアローンビデオゲームソフトウェアのための成功が見込める市場が本質的にない。というのは、ユーザが海賊版コピーを合法的コピーと同程度に容易にそのコストのほんの一部分で買えるからである。又、世界の多くの地域では、ゲームコンソールのコストが収入の高い割合であり、海賊版を取り締まっても、最新のゲームシステムを買う余裕がある人は僅かに過ぎない。]
[0055] 更に、中古ゲーム市場は、ビデオゲーム産業の収入を減少させる。ユーザは、ゲームに飽きると、ゲームを店に売ることができ、店は、ゲームを他のユーザに再販売する。この無許可であるが一般的な慣習は、ゲーム発行者の収入を著しく減少させる。同様に、数年毎にプラットホームの移行があるときには、通常、５０％の販売量低下が生じる。これは、ユーザが、新規バージョンプラットホームが発売されようとしていることを知ると、旧型プラットホーム用のゲームの購入を止める（例えば、Ｐｌａｙｓｔａｔｉｏｎ３が発売されようとしているときに、ユーザは、Ｐｌａｙｓｔａｔｉｏｎ２のゲームの購入を止める）からである。新規のプラットホームに関連した販売の損失及び開発コストの増加が相まって、ゲーム開発者の利益に非常に大きな影響が及ぶことになる。]
[0056] 又、新規なゲームコンソールは、非常に高価である。ＸＢｏｘ ３６０、Ｎｉｎｔｅｎｄｏ Ｗｉｉ、及びＳｏｎｙ Ｐｌａｙｓｔａｔｉｏｎ３は、全て、数百ドルで小売される。ハイパワーのパーソナルコンピュータゲームシステムは、その価格が＄８０００までである。これは、特に、ハードウェアが数年後に旧式となり且つ多くのシステムが子供のために購入されることを考えると、ユーザにとって著しい投資を表す。]
[0057] 以上の問題に対する１つの解決策は、ゲームプログラムコード及びデータがサーバーにホストされそしてオンデマンドでクライアントマシンへデジタルブロードバンドネットワークを経てストリーミングされる圧縮されたビデオ及びオーディオとして配信されるオンラインゲームである。フィンランドのＧ−Ｃｌｕｓｔｅｒ（現在では、日本のソフトバンクブロードメディアの子会社）のような幾つかの会社は、これらのサービスをオンラインで提供する。同様のゲームサービスが、ホテル内にあるようなローカルネットワークにおいて利用でき、ＤＳＬ及びケーブルテレビジョンプロバイダーによって提供されている。これらシステムの主たる欠点は、待ち時間(latency)、即ちオペレータの「ヘッドエンド」に典型的に配置されたゲームサーバーへ信号が進み且つそこから進むのに要する時間の問題である。高速アクションビデオゲーム（「ツイッチ」ビデオゲームとしても知られている）は、ユーザがゲームコントローラでアクションを遂行する時間と、ディスプレイスクリーンが更新されてユーザアクションの結果を示す時間との間に非常に短い待ち時間を要求する。ゲームが「即座」に応答するという感覚をユーザがもつようにするため、短い待ち時間が必要とされる。ユーザは、ゲームの形式及びユーザの熟練度レベルに基づいて異なる待ち時間間隔で満足することができる。例えば、ゆっくりしたカジュアルなゲーム（バックギャモンのような）又は低速アクションの役割を演じるゲームについては１００ｍｓの待ち時間が許容できるが、高速アクションゲームでは、待ち時間が７０又は８０ｍｓを越えると、ユーザは、ゲームにおいて演技が不充分となり、受け容れられない。例えば、高速反応時間を要求するゲームでは、待ち時間が５０から１００ｍｓへ増加するにつれて、精度が鋭く低下する。]
[0058] ゲーム又はアプリケーションサーバーが、近傍のコントロールされたネットワーク環境にインストールされるか、又はユーザへのネットワーク経路が予想可能で及び／又は帯域巾ピークを許容できる環境にインストールされるときには、最大待ち時間と、待ち時間の一貫性の両方について、待ち時間をコントロールすることが遥かに容易である（例えば、ユーザがネットワークを通してストリーミングするデジタルビデオから一定の動きを観察するように）。このようなレベルのコントロールは、ケーブルＴＶネットワークのヘッドエンドとケーブルＴＶ加入者の家庭との間、又はＤＳＬ中央オフィスからＤＳＬ加入者の家庭までの間、或いはサーバー又はユーザからの商業的オフィスのローカルエリアネットワーク（ＬＡＮ）環境において、達成することができる。又、保証された帯域巾及び待ち時間を有する会社間に特殊グレードのポイント対ポイントプライベート接続を得ることができる。しかし、一般的なインターネットに接続されたサーバーセンターにおいてゲームをホストし、次いで、ブロードバンド接続を経てユーザへ圧縮ビデオをストリーミングするゲーム又はアプリケーションシステムでは、多数のファクタから待ち時間を招き、従来システムの展開に甚だしい制限を生じさせる。]
[0059] 典型的なブロードバンド接続の家庭では、ユーザは、ブロードバンドサービスのためにＤＳＬ又はケーブルモデムをもつことができる。このようなブロードバンドサービスは、通常、ユーザの家庭と一般的なインターネットとの間に２５ｍｓ程度（時々はそれ以上の）の往復待ち時間を被る。更に、インターネットを経てサーバーセンターへデータをルーティングすることからも往復遅延を被る。インターネットを通しての待ち時間は、データが与えられるルート及びそれがルーティングされるときに被る遅延に基づいて変化する。ルーティング遅延に加えて、ほとんどのインターネットを相互接続する光ファイバを経て進む光の速度のために、往復遅延も被る。例えば、１０００マイルごとに、光ファイバを通る光の速度及び他のオーバーヘッドのために、約２２ｍｓの往復待ち時間を被る。]
[0060] インターネットを経てストリーミングされるデータのデータレートのために、付加的な待ち時間が生じる。例えば、ユーザが「６ＭｂｐｓＤＳＬサービス」として販売されるＤＳＬサービスを有する場合に、実際に、ユーザは、おそらく、せいぜい５Ｍｂｐｓ未満のダウンストリームスループットしか得ず、そしておそらく、デジタルサブスクライバーラインアクセスマルチプレクサ（ＤＳＬＡＭ）におけるピークロード時間中の混雑のような種々のファクタのために、接続の質低下を周期的に見ることになる。又、ケーブルモデムシステムネットワークにおける隣接部又は他のどこかを経てループされるローカル共有同軸ケーブルに混雑が生じる場合には、「６Ｍｂｐｓケーブルモデムサービス」として販売される接続に使用されるケーブルモデムのデータレートを遥かに低く減少する同様の問題が発生する。４Ｍｂｐｓの一定レートでのデータパケットがサーバーセンターからこのような接続を経てユーザデータグラムプロトコル（ＵＤＰ）フォーマットで一方向としてストリーミングされる場合には、全てがうまく機能すれば、データパケットが、付加的な待ち時間を被ることなく通過するが、混雑（又は他の障害）が存在し且つユーザへデータをストリーミングするのに３．５Ｍｂｐｓしか利用できない場合には、典型的な状態において、パケットがドロップされてデータロスを生じるか、又はパケットを送ることができるまで混雑点にパケットがキューイングされて付加的な待ち時間を招くか、のいずれかである。異なる混雑点は、遅延パケットを保持する異なるキューイング容量を有し、従って、あるケースでは、混雑を通過できないパケットが直ちにドロップされる。他のケースでは、数メガビットのデータがキューイングされ、最終的に、送出される。しかし、ほぼ全てのケースにおいて、混雑点におけるキューは、容量限界があり、これらの限界を越えると、キューがオーバーフローし、パケットがドロップされる。従って、付加的な待ち時間（又は更に悪い場合は、パケットのロス）を被るのを回避するために、ゲーム又はアプリケーションサーバーからユーザへのデータレート容量を越えないようにする必要がある。]
[0061] 又、サーバーにおいてビデオを圧縮しそしてクライアント装置においてビデオを解凍するのに要求される時間によっても待ち時間を被る。更に、サーバー上で実行されているビデオゲームが、表示されるべき次のフレームを計算する間にも待ち時間を被る。現在入手できるビデオ圧縮アルゴリズムは、高いデータレート又は長い待ち時間のいずれかで悩まされている。例えば、モーションＪＰＥＧは、待ち時間が短いことを特徴とするイントラフレーム専用ロッシー(intra frame-only lossy)圧縮アルゴリズムである。各ビデオフレームは、互いのビデオフレームと独立して圧縮される。クライアント装置は、圧縮されたモーションＪＰＥＧビデオのフレームを受け取ると、そのフレームを直ちに解凍して表示し、待ち時間を非常に短くする。しかし、各フレームは、別々に圧縮されるので、アルゴリズムは、連続するフレーム間の類似性を利用することができず、その結果、イントラフレーム専用ビデオ圧縮アルゴリズムは、非常に高いデータレートで悩まされている。例えば、６０ｆｐｓ（フレーム／秒）６４０ｘ４８０モーションＪＰＥＧビデオは、４０Ｍｂｐｓ（メガビット／秒）以上のデータを要求する。このように低い解像度のビデオウインドウに対するこのように高いデータレートは、多くのブロードバンドアプリケーションにおいて（及び確実にほとんどの消費者インターネットベースのアプリケーションに対して）法外に高価なものとなる。更に、各フレームは独立して圧縮されるので、ロッシー圧縮から生じ得るフレーム内の欠陥は、おそらく、連続するフレームの異なる場所に現れる。これは、ビデオが解凍されたときに、動く視覚上の欠陥として視聴者に見える。]
[0062] マイクロソフト社からのＭＰＥＧ２、Ｈ．２６４、又はＶＣ９のような他の圧縮アルゴリズムは、従来の構成で使用されたときに、高い圧縮比を達成できるが、長い待ち時間が犠牲となる。このようなアルゴリズムは、インターフレーム及びイントラフレームの圧縮を使用する。周期的に、このようなアルゴリズムは、フレームのイントラフレーム専用圧縮を遂行する。このようなフレームは、キーフレーム（典型的に“Ｉ”フレームと称される）として知られている。次いで、これらのアルゴリズムは、典型的に、Ｉフレームを手前のフレーム及び連続するフレームの両方と比較する。手前のフレーム及び連続するフレームを独立して圧縮するのではなく、このアルゴリズムは、Ｉフレームから手前のフレーム及び連続するフレームへと映像の何が変化したか決定し、次いで、それらの変化を、Ｉフレームに先行する変化については“Ｂ”フレームとして、及びＩフレームに続く変化については“Ｐ”フレームとして記憶する。これは、イントラフレーム専用圧縮よりも非常にゆっくりしたデータレートを生じさせる。しかし、これは、典型的に、長い待ち時間を犠牲とする。Ｉフレームは、典型的に、Ｂ又はＰフレームより非常に大きく（しばしば１０倍以上）、その結果、所与のデータレートで送信するのに比例的に長い時間を要する。]
[0063] 例えば、Ｉフレームが、Ｂ及びＰフレームのサイズの１０倍であり、単一のＩイントラフレームごとに２９個のＢフレーム＋３０個のＰフレーム＝５９個のインターフレームがあるか、又は「フレームグループ（ＧＯＰ）」ごとに合計６０個のフレームがある状態を考える。従って、６０ｆｐｓでは、毎秒１つの６０フレームＧＯＰがある。送信チャンネルが２Ｍｂｐｓの最大データレートを有すると仮定する。チャンネルに最高クオリティのビデオを得るために、圧縮アルゴリズムは、２Ｍｂｐｓのデータストリームを発生し、上述した比を仮定すれば、これは、２メガビット（Ｍｂ）／（５９＋１０）＝３０，３９４ビット／イントラフレーム及び３０３，９３５ビット／Ｉフレームを生じさせる。圧縮されたビデオストリームが解凍アルゴリズムによって受信されるときには、ビデオを着実にプレイするために、各フレームを規則的な間隔（例えば、６０ｆｐｓ）で解凍して表示する必要がある。この結果を得るために、フレームが送信待ち時間を受ける場合には、全てのフレームを少なくともその待ち時間だけ遅延する必要があり、従って、最悪のケースのフレーム待ち時間は、各ビデオフレームに対する待ち時間を定義する。Ｉフレームは、最も大きなものであるから、最長の送信待ち時間を導入し、Ｉフレームを解凍して表示できるまでにＩフレーム全体を受信しなければならない（又はインターフレームがＩフレームに依存する）。チャンネルデータレートが２Ｍｂｐｓであると仮定すれば、Ｉフレームを送信するのに、３０３，９３５／２Ｍｂ＝１４５ｍｓを要することになる。]
[0064] 送信チャンネルの帯域巾の大部分を使用する上述したインターフレームビデオ圧縮システムは、フレームの平均サイズに対してＩフレームのサイズが大きいために長い待ち時間を受けることになる。又は、換言すれば、従来のインターフレーム圧縮アルゴリズムは、イントラフレーム専用圧縮アルゴリズムより低いフレーム当たり平均データレートを達成するが（例えば、２Ｍｂｐｓ対４０Ｍｂｐｓ）、大きなＩフレームのために、依然、高いフレーム当たりピークデータレートで悩まされている（例えば、３０３，９３５＊６０＝１８．２Ｍｂｐｓ）。前記分析は、Ｐ及びＢの両フレームがＩフレームより非常に小さいと仮定していることを銘記されたい。これは、一般的には、真であるが、高い映像複雑さが手前のフレーム、高モーション又はシーンの変化に相関していないフレームについては真ではない。このような状態では、Ｐ又はＢフレームがＩフレームと同程度の大きさになる（Ｐ又はＢフレームがＩフレームより大きくなると、精巧な圧縮アルゴリズムが、典型的に、Ｉフレームを「強制(force)」し、そしてＰ又はＢフレームをＩフレームに置き換える）。従って、デジタルビデオストリームには、いつでも、Ｉフレームサイズのデータレートピークが生じる。従って、圧縮されたビデオでは、平均ビデオデータレートが送信チャンネルのデータレート容量に接近するときに（ビデオに対する高いデータレート要求を仮定すると、しばしばそうである）、Ｉフレーム或いは大きなＰ又はＢフレームからの高いピークデータレートが長いフレーム待ち時間を生じさせる。]
[0065] もちろん、以上の説明は、ＧＯＰにおける大きなＢ、Ｐ又はＩフレームによって生じる圧縮アルゴリズムの待ち時間を特徴付けるに過ぎない。Ｂフレームが使用される場合は、待ち時間がより長くなる。その理由は、Ｂフレームを表示できるまでに、Ｂフレーム及びＩフレーム後の全てのＢフレームを受信しなければならないからである。従って、各Ｉフレームの前に５個のＢフレームがあるＢＢＢＢＢＩＰＰＰＰＰＢＢＢＢＢＩＰＰＰＰＰのような画像グループ（ＧＯＰ）シーケンスにおいて、最初のＢフレームは、その後のＢフレーム及びＩフレームが受信されるまでビデオデコンプレッサによって表示することができない。従って、ビデオが６０ｆｐｓ（即ち、１６．６７ｍｓ／フレーム）でストリーミングされる場合には、最初のＢフレームを解凍できるまでに、チャンネル帯域巾がどれほど速くても、５個のＢフレーム及びＩフレームは、受信するのに１６．６７＊６＝１００ｍｓを要し、これは、ちょうど、５個のＢフレームである。３０個のＢフレームをもつ圧縮されたビデオシーケンスは、極めて一般的である。そして、２Ｍｂｐｓのような低いチャンネル帯域巾では、Ｉフレームのサイズにより生じる待ち時間の影響が、主として、Ｂフレームが到着するのを待機することによる待ち時間の影響に加えられる。従って、２Ｍｂｐｓチャンネルにおいて、非常に多数のＢフレームがある状態では、従来のビデオ圧縮技術を使用して、５００ｍｓ以上の待ち時間を越えるのは極めて容易である。Ｂフレームが使用されない（所与のクオリティレベルに対して低い圧縮比を犠牲にして）場合には、Ｂフレームの待ち時間を被らないが、上述したピークフレームサイズにより生じる待ち時間は、依然、被る。]
[0066] この問題は、まさに多数のビデオゲームの性質により激化される。上述したＧＯＰ構造を使用するビデオ圧縮アルゴリズムは、主として、受動的な視聴に意図された生のビデオ又は動画資料で、使用上最適化されている。典型的に、カメラ（実際のカメラであるか、コンピュータ発生アニメーションの場合のバーチャルカメラであるかに関わらず）、及びシーンは、比較的安定である。というのは、単に、カメラ又はシーンがあまりに急に動く場合に、ビデオ又は映画資料が、（ａ）典型的に見るのに不快であり、そして（ｂ）それを見る場合に、カメラが突然グイと動くときに、通常、視聴者がアクションを厳密に追従できないからである（例えば、バースディケーキのキャンドルに息を吹きかける子供を撮影するときにカメラがバンプされ、そして突然ケーキから離れて戻るようにグイと動かされる場合に、視聴者は、典型的に、子供及びケーキに集中し、カメラが突然動くときの短い中断は無視する）。ビデオのインタビュー又はビデオ遠隔会議のケースでは、カメラを固定位置に保持して、全く動かさず、非常に僅かなデータピークしか生じさせない。しかし、３Ｄ高アクションビデオゲームは、一定の動きにより特徴付けられる（例えば、レースの期間中に全フレームが迅速な動きにあるような３Ｄレースを考えるか、又はバーチャルカメラが常にグイと動くようなファーストパーソンシューター(first-person shooter)を考える）。このようなビデオゲームは、これらの突然の動きの間に何が起きたかユーザがはっきり見る必要があるところの大きなそして頻繁なピークを伴うフレームシーケンスを生じさせる。従って、３Ｄ高アクションビデオゲームでは、圧縮欠陥は、ほとんど許容できない。従って、多くのビデオゲームのビデオ出力は、それらの性質により、非常に高く且つ頻繁なピークをもつ圧縮ビデオストリームを発生する。]
[0067] 高速アクションビデオゲームのユーザが長い待ち時間に対してあまり寛容度がないと仮定し、又、上述した全ての待ち時間の原因を仮定すれば、今日まで、インターネットを経てビデオをストリーミングするサーバーホスト型ビデオゲームには制限があった。更に、高度の双方向性を要求するアプリケーションのユーザは、そのアプリケーションが一般的なインターネット及びストリームビデオでホストされる場合には、同様に制限で悩まされている。このようなサービスは、ホスティングサーバーが、商業的な設定において、ヘッドエンド（ケーブルブロードバンドの場合）、又は中央オフィス（デジタルサブスクライバーライン（ＤＳＬ）の場合）、或いはＬＡＮ（又は特殊グレードのプライベート接続）内に直接設定されて、クライアント装置からサーバーへのルート及び距離が待ち時間を最小にするように制御され、且つ待ち時間を被ることなくピークを受け容れできるようなネットワークコンフィギュレーションを要求する。ＬＡＮ（典型的に１００Ｍｂｐｓから１Ｇｂｐｓ定格）及び充分な帯域巾の賃貸ラインは、典型的に、ピーク帯域巾要求をサポートすることができる（例えば、１８Ｍｂｐｓのピーク帯域巾は、１００ＭｂｐｓのＬＡＮ容量の小部分である）。]
[0068] 又、ピーク帯域巾要求は、特殊な受け容れがなされる場合には、住居用ブロードバンドインフラストラクチャーにより受け容れることができる。例えば、ケーブルＴＶシステムでは、デジタルビデオトラフィックに、大きなＩフレームのようなピークを取り扱うことのできる専用帯域巾が与えられる。そしてＤＳＬシステムでは、高速ＤＳＬモデムを準備して、高いピークを許すことができるか、又は高いデータレートを取り扱うことのできる特殊グレードの接続を準備することができる。しかし、一般的なインターネットに取り付けられる従来のケーブルモデム及びＤＳＬインフラストラクチャーは、圧縮ビデオのピーク帯域要件に対して遥かに低い寛容度しか有していない。従って、クライアント装置から長距離にあるサーバーセンターにおいてビデオゲーム又はアプリケーションをホストし、次いで、インターネットを経て従来の住居用ブロードバンド接続を通して圧縮ビデオ出力をストリーミングするオンラインサービスは、特に、非常に短い待ち時間を要求するゲーム及びアプリケーション（例えば、ファーストパーソンシューター及び他のマルチユーザ双方向アクションゲーム、又は高速応答時間を要求するアプリケーション）に関して、顕著な待ち時間及びピーク帯域巾制限で悩まされている。]
[0069] 本開示は、添付図面及び以下の詳細な説明から、より完全に理解されよう。しかしながら、ここに開示した要旨は、本発明を例示するものに過ぎず、ここに示す特定の実施形態に限定されるものではない。]
図面の簡単な説明

[0070] 従来のビデオゲームシステムのアーキテクチャーを示す。
一実施形態による高レベルシステムアーキテクチャーを示す。
一実施形態による高レベルシステムアーキテクチャーを示す。
クライアントとサーバーとの間の通信に対する実際のデータレート、定格データレート、及び要求されるデータレートを示す。
一実施形態により使用されたホスティングサービス及びクライアントを示す。
クライアントとホスティングサービスとの間の通信に関連した例示的待ち時間を示す。
一実施形態によるクライアント装置を示す。
別の実施形態によるクライアント装置を示す。
図４ｃのクライアント装置のブロック図である。
図４ｄのクライアント装置のブロック図である。
一実施形態により使用できるビデオ圧縮の一形式を例示する。
別の実施形態に使用できるビデオ圧縮の一形式を例示する。
低い複雑さ、低アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。
高い複雑さ、高アクションのビデオシーケンスの送信に関連したデータレートのピークを示す。
一実施形態に使用されるビデオ圧縮技術を示す。
一実施形態に使用されるビデオ圧縮技術を示す。
一実施形態に使用される付加的なビデオ圧縮技術を示す。
データレートピークを緩和するために一実施形態に使用される技術を示す。
データレートピークを緩和するために一実施形態に使用される技術を示す。
データレートピークを緩和するために一実施形態に使用される技術を示す。
映像タイルをパケット内に効率的にパックする一実施形態を示す。
映像タイルをパケット内に効率的にパックする一実施形態を示す。
順方向エラー修正技術を使用する実施形態を示す。
順方向エラー修正技術を使用する実施形態を示す。
順方向エラー修正技術を使用する実施形態を示す。
順方向エラー修正技術を使用する実施形態を示す。
圧縮のためのマルチコア処理ユニットを示す一実施形態を示す。
実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。
実施形態による地理的ポジショニング及びホスティングサービス間の通信を示す。
クライアントとホスティングサービスとの間の通信に関連した待ち時間を例示する。
ホスティングサービスのサーバーセンターアーキテクチャーを示す。
複数の生のビデオウインドウを含むユーザインターフェイスの一実施形態のスクリーンショットを例示する。
特定のビデオウインドウを選択した後の図１６のユーザインターフェイスを示す。
特定のビデオウインドウをフルスクリーンサイズへズーミングした後の図１７のユーザインターフェイスを示す。
マルチプレーヤゲームのスクリーンにオーバーレイされる共同ユーザビデオデータを例示する。
ホスティングサービスにおけるゲームプレーヤのためのユーザページを例示する。
３Ｄ双方向広告を例示する。
生の演技の表面捕獲からのテクスチャ処理表面を有するホトリアルな映像を発生するための一連のステップを例示する。
リニアメディアコンテンツの選択を許すユーザインターフェイスページを例示する。
ウェブページが生である前に経過する時間長さを接続速度に対して示すグラフである。] 図１６ 図１７ 図４ｃ 図４ｄ
実施例

[0071] 以下の説明では、本開示を完全に理解するために、装置の形式、システムコンフィギュレーション、通信方法、等の特定の細部について述べる。しかしながら、当業者であれば、ここに述べる実施形態を具現化するのに、これらの特定の細部は必要ないことが明らかであろう。]
[0072] 図２ａ−ｂは、ビデオゲーム及びソフトウェアアプリケーションが、契約サービスのもとでインターネット２０６（或いは他のパブリック又はプライベートネットワーク）を経てユーザの家屋２１１（「ユーザの家屋」とは、ユーザが所在する場所を意味し、移動装置を使用する場合には屋外も含む）においてホスティングサービス２１０によりホストされそしてクライアント装置２０５によりアクセスされるような２つの実施形態の高レベルアーキテクチャーを示す。クライアント装置２０５は、内部又は外部ディスプレイ装置２２２を有していてインターネットにワイヤード又はワイヤレス接続されるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ又はＬｉｎｕｘベースのＰＣ又はＡｐｐｌｅ社のＭａｃｉｎｔｏｓｈコンピュータのような汎用コンピュータでもよいし、又はビデオ及びオーディオをモニタ又はＴＶ受像機２２２へ出力するセットトップボックス（インターネットにワイヤード又はワイヤレス接続される）のような専用クライアント装置でもよいし、或いはおそらくインターネットにワイヤレス接続される移動装置でもよい。] 図２ａ
[0073] これらの装置は、いずれも、それ自身のユーザ入力装置（例えば、キーボード、ボタン、タッチスクリーン、トラックパッド又は慣性感知棒、ビデオ捕獲カメラ及び／又は運動追跡カメラ、等）を有してもよいし、又は有線又は無線で接続された外部入力装置２２１（例えば、キーボード、マウス、ゲームコントローラ、慣性感知棒、ビデオ捕獲カメラ、及び／又は運動追跡カメラ、等）を使用してもよい。以下に詳細に述べるように、ホスティングサービス２１０は、高パワーのＣＰＵ／ＧＰＵ処理能力を伴うものを含めて、種々の性能レベルのサーバーを含む。ゲームのプレイ中、又はホスティングサービス２１０におけるアプリケーションの使用中に、家庭又はオフィス用のクライアント装置２０５は、ユーザからのキーボード及び／又はコントローラ入力を受け取り、次いで、インターネット２０６を通してホスティングサービス２１０へコントローラ入力を送信し、このホスティングサービス２１０は、それに応答してゲームプログラムを実行し、そしてゲーム又はアプリケーションソフトウェアのためのビデオ出力の連続フレーム（一連のビデオ映像）を発生する（例えば、ユーザがボタンを押して、スクリーン上のキャラクタを右へ移動するように指令する場合には、ゲームプログラムが、右へ移動するキャラクタを示す一連のビデオ映像を生成する）。この一連のビデオ映像は、次いで、短待ち時間のビデオコンプレッサを使用して圧縮され、次いで、ホスティングサービス２１０は、インターネット２０６を通して短待ち時間のビデオストリームを送信する。家庭又はオフィス用クライアント装置は、次いで、圧縮されたビデオストリームをデコードし、そしてモニタ又はＴＶにおいてその解凍されたビデオ映像をレンダリングする。その結果、クライアント装置２０５のコンピューティング及びグラフィックハードウェア要件が著しく緩和される。クライアント２０５は、キーボード／コントローラ入力をインターネット２０６へ転送し、そしてインターネット２０６から受け取った圧縮されたビデオストリームをデコードし解凍するための処理パワーを有するだけでよく、これは、実質上、パーソナルコンピュータが、今日、そのＣＰＵにおいてソフトウケアで実行できることである（例えば、ほぼ２ＧＨｚで実行されるインテル社のＣｏｒｅ Ｄｕｏ ＣＰＵは、Ｈ．２６４及びＷｉｎｄｏｗｓ ＭｅｄｉａＶＣ９のようなコンプレッサを使用してエンコードされた７２０ｐＨＤＴＶを解凍することができる）。そして、クライアント装置のケースでは、専用のチップも、このような規格に対するビデオ解凍を、リアルタイムで、遥かに低いコストにおいて、且つ近代的なＰＣに要求されるような汎用ＣＰＵより遥かに低い消費電力で遂行することができる。特に、コントローラ入力を転送しそしてビデオを解凍する機能を遂行するために、家庭用クライアント装置２０５は、特殊なグラフィック処理ユニット（ＧＰＵ）、光学的ドライブ又はハードドライブ、例えば、図１に示す従来のビデオゲームシステムを要求しない。] 図１
[0074] ゲーム及びアプリケーションソフトウェアが、より複雑になり且つよりホトリアリスティックになるにつれて、それらは、高性能ＣＰＵ、ＧＰＵ、より多くのＲＡＭ、及びより大きくて高速のディスクドライブを要求し、且つホスティングサービス２１０のコンピューティングパワーは、アップグレードし続けるが、エンドユーザは、家庭又はオフィス用のクライアントプラットホーム２０５を更新することが要求されない。というのは、その処理要件は、所与のビデオ解凍アルゴリズムでの表示解像度及びフレームレートに対して一定のままだからである。従って、図２ａ−ｂに示すシステムには、今日見られるハードウェア制限及び互換性の問題が生じない。] 図２ａ
[0075] 更に、ゲーム及びアプリケーションソフトウェアは、ホスティングサービス２１０のサーバーでのみ実行されるので、ゲーム又はアプリケーションソフトウェアのコピー（光学的メディアの形態又はダウンロードされたソフトウェアとして）がユーザの家庭又はオフィスに存在することはない（ここで使用する「オフィス」とは、特に指示のない限り、例えば、学校の教室を含めて、非住居設定を含むものとする）。これは、ゲーム又はアプリケーションソフトウェアが不法にコピーされる（海賊版作成される）おそれを著しく軽減すると共に、海賊版作成されるゲーム又はアプリケーションにより貴重なデータベースが使用されるおそれを軽減する。実際に、家庭又はオフィスでの使用に実際的でないゲーム又はアプリケーションソフトウェアをプレイするために特殊なサーバーが要求される（例えば、非常に高価で、大きく又はノイズを発生する装置が要求される）場合には、ゲーム又はアプリケーションソフトウェアの海賊版コピーが得られたとしても、家庭又はオフィスで動作することはできない。]
[0076] 一実施形態では、ホスティングサービス２１０は、ソフトウェア開発ツールをゲーム又はアプリケーションソフトウェア開発者（一般的に、ソフトウェア開発会社、ゲーム又は映画スタジオ、或いはゲーム又はアプリケーションソフトウェア発行者を指す）２２０に与え、この開発者は、ホスティングサービス２１０において実行できるゲームを設計するようにビデオゲームを設計する。そのようなツールは、スタンドアローンＰＣ又はビデオゲームコンソールでは通常利用できないホスティングサービスの特徴を開発者が利用できるようにする（例えば、複雑な幾何学形状の非常に大きなデータベースへの高速アクセス（「幾何学形状」とは、特に指示のない限り、ここでは、多角形、テクスチャ、リギング、照明、挙動、並びに３Ｄデータベースを定義する他のコンポーネント及びパラメータを指すものとする））。]
[0077] このアーキテクチャーのもとでは、異なるビジネスモデルが考えられる。１つのモデルのもとで、ホスティングサービス２１０は、図２ａに示すように、エンドユーザから契約料金を収集し、そして開発者２２０にロイヤリティを支払う。図２ｂに示す別の具現化においては、開発者２２０がユーザから契約料金を直接収集し、そしてゲーム又はアプリケーションコンテンツをホストするためにホスティングサービス２１０に支払をする。これらの基礎的な原理は、オンラインゲーム又はアプリケーションホスティングを提供するための特定のビジネスモデルに限定されない。] 図２ａ 図２ｂ
[0078] 圧縮ビデオ特性
上述したように、ビデオゲームサービス又はアプリケーションソフトウェアサービスをオンラインで提供することに伴う１つの顕著な問題は、待ち時間である。（ユーザにより入力装置が操作される点から、ディスプレイ装置に応答が表示される点までの）７０から８０ｍｓの待ち時間が、高速応答時間を要求するゲーム及びアプリケーションの上限である。しかしながら、図２ａ及び２ｂに示すアーキテクチャーの環境では多数の実際的及び物理的な制約があるために、これを達成することが非常に困難である。] 図２ａ
[0079] 図３に示すように、ユーザがインターネットサービスに契約するときに、その接続は、典型的に、ユーザの家庭又はオフィスへの公称最大データレート３０１によって定格付けされる。プロバイダーのポリシー及びルーティング装置の能力に基づいて、その最大データレートは、若干厳格に施行できるが、典型的に、実際に得られるデータレートは、多数の異なる理由の１つで、低いものとなる。例えば、ＤＳＬ中央オフィス又はローカルケーブルモデムループに非常に多くのネットワークトラフィックがあるか、又はケーブルにノイズが生じてパケットをドロップさせるか、或いはプロバイダーが最大ビット数／月／ユーザを確立することがある。現在、ケーブル及びＤＳＬサービスに対する最大ダウンストリームデータレートは、典型的に、数百キロビット／秒（Ｋｂｐｓ）から３０Ｍｂｐｓの範囲である。セルラーサービスは、典型的に、数百Ｋｂｐｓのダウンストリームデータに制限される。しかしながら、ブロードバンドサービスの速度及びブロードバンドサービスに契約するユーザの数は、時間と共に急激に増加する。現在、ある分析では、米国のブロードバンド加入者の３３％が２Ｍｂｐｓ以上のダウンストリームデータレートを有することが推定される。例えば、ある分析では、２０１０年までに、米国のブロードバンド加入者の８５％以上が２Ｍｂｐｓ以上のデータレートを有することが推定される。] 図３
[0080] 図３に示すように、実際に利用可能な最大データレート３０２は、時間と共に変動し得る。従って、短い待ち時間のオンラインゲーム又はアプリケーションソフトウェアコンテクストでは、時々、特定のビデオストリームに対する実際に利用できるデータレートを予想することが困難である。所与の数値のフレーム／秒（ｆｐｓ）における所与のレベルのクオリティをある量のシーンの複雑さに対し所与の解像度（例えば、６４０ｘ４８０＠６０ｆｐｓ）において維持するためにデータレート３０３が要求され、そして（図３にピークで示されるように）実際に利用できる最大データレート３０２より上に動きが上昇する場合には、多数の問題が発生し得る。例えば、あるインターネットサービスは、単にパケットをドロップし、ユーザのビデオスクリーンにデータロス及び映像歪／ロスを招くことになる。他のサービスは、付加的なパケットを一時的にバッファし（即ち、キューイングし）、そして利用可能なデータレートでクライアントへパケットを与えて、待ち時間の増加、即ち多数のビデオゲーム及びアプリケーションにとって受け容れられない結果を招くことになる。最終的に、あるインターネットサービスプロバイダーは、データレートの増加を、悪意のある攻撃、例えば、サービス拒否攻撃（ネットワーク接続を無能化するためにハッカーにより使用される良く知られた技術）とみなし、そしてユーザのインターネット接続を指定期間中切断する。従って、ここに述べる実施形態は、ビデオゲームに要求されるデータレートが、利用可能な最大データレートを越えないことを保証するステップをとる。] 図３
[0081] ホスティングサービスアーキテクチャー
図４ａは、一実施形態によるホスティングサービス２１０のアーキテクチャーを示す。ホスティングサービス２１０は、単一サーバーセンターに配置することもできるし、又は複数のサーバーセンターにわたり分散することもできる（あるサーバーセンターへの経路が他のサーバーセンターより短い待ち時間となる短待ち時間接続をユーザに与え、ユーザ間に負荷バランスを与え、そして１つ以上のサーバーセンターがフェイルする場合に冗長性を与えるために）。ホスティングサービス２１０は、最終的に、数百又は数千或いは数百万のサーバー４０２を含み、非常に大きなユーザベースにサービスすることができる。ホスティングサービスコントロールシステム４０１は、ホスティングサービス２１０に対する全体的なコントロールを与え、ルーター、サーバー、ビデオ圧縮システム、ビリング及びアカウンティングシステム、等に指令する。一実施形態では、ホスティングサービスコントロールシステム４０１は、ユーザ情報、サーバー情報及びシステム統計情報のためのデータベースを記憶するのに使用されるＲＡＩＤアレイに結合された分散処理Ｌｉｎｕｘベースシステムにおいて具現化される。以上の説明では、ホスティングサービス２１０により具現化される種々のアクションは、他の特定システムに起因しない限り、ホスティングサービスコントロールシステム４０１により開始されコントロールされる。] 図４ａ
[0082] ホスティングサービス２１０は、インテル、ＩＢＭ、ヒューレットパッカード、等から現在入手できるもののような多数のサーバー４０２を含む。或いは又、サーバー４０２は、コンポーネントのカスタム構成でアッセンブルすることもできるし、又は全サーバーが単一チップとして具現化されるように最終的に一体化することもできる。この図は、図示明瞭化のために、少数のサーバー４０２しか示していないが、実際の展開では、１つ程度のサーバー４０２があってもよいし、又は数百万以上のサーバー４０２があってもよい。サーバー４０２は、全てが同様に構成されてもよいし（幾つかの構成パラメータの例として、同じＣＰＵ形式及び性能で、ＧＰＵをもったりもたなかったりして、そしてＧＰＵをもつ場合には、同じＧＰＵ形式及び性能で、又、同じ数のＣＰＵ及びＧＰＵで、又、同じ量及び形式／速度のＲＡＭで、並びに同じＲＡＭ構成で）、又はサーバー４０２の種々のサブセットが同じ構成を有してもよいし（例えば、サーバーの２５％をある仕方で構成することができ、５０％を異なる仕方で構成することができ、そして２５％を更に別の仕方で構成することができ）、或いは各サーバー４０２が異なるものでもよい。]
[0083] 一実施形態では、サーバー４０２は、ディスクレスであり、即ちそれ自身のローカル大量記憶装置（光学又は磁気記憶装置、或いは半導体ベースの記憶装置、例えば、フラッシュメモリ又は同様の機能を果たす他の大量記憶手段）を有するのではなく、各サーバーは、高速バックプレーン又はネットワーク接続を通して共有大量記憶装置にアクセスする。一実施形態では、この高速接続は、一連の独立ディスク冗長アレイ（ＲＡＩＤ）４０５に接続された記憶エリアネットワーク（ＳＡＮ）４０３であり、装置間の接続がギガビットイーサネット（登録商標）を使用して具現化される。当業者に明らかなように、ＳＡＮ４０３は、多数のＲＡＩＤアレイ４０５を一緒に合成して、最終的に広い帯域巾を生じさせ、即ち現在のゲームコンソール及びＰＣに使用されるＲＡＭから得られる帯域巾に接近するか又はそれを潜在的に越えるのに使用される。そして、磁気メディアのような回転メディアをベースとするＲＡＩＤアレイは、著しいシーク時間アクセス待ち時間をしばしば有するが、半導体記憶装置をベースとするＲＡＩＤアレイは、相当に短いアクセス待ち時間で具現化することができる。別の構成では、サーバー４０２の幾つか又は全部が、それら自身の大量記憶装置の幾つか又は全部をローカルで与える。例えば、サーバー４０２は、そのオペレーティングシステムのような頻繁にアクセスされる情報、及びビデオゲーム又はアプリケーションのコピーを短待ち時間のローカルフラッシュベースの記憶装置に記憶するが、幾何学形状又はゲーム状態情報の大きなデータベースに時々アクセスするには、ＳＡＮを使用して、回転メディアをベースとするＲＡＩＤアレイ４０５に大きなシーク待ち時間でアクセスする。]
[0084] 更に、一実施形態では、ホスティングサービス２１０は、以下に詳細に説明する短待ち時間のビデオ圧縮ロジック４０４を使用する。このビデオ圧縮ロジック４０４は、ソフトウェア、ハードウェア又はその組合せで具現化することができる（その幾つかの実施形態を以下に説明する）。ビデオ圧縮ロジック４０４は、オーディオ及びビジュアル資料を圧縮するためのロジックを含む。]
[0085] 動作に際し、ユーザの家屋２１１において、キーボード、マウス、ゲームコントローラ又は他の入力装置４２１を経てビデオゲームをプレイするか又はアプリケーションを使用する間に、クライアント４１５のコントロール信号ロジック４１３は、ユーザにより作動されたボタン押圧（及び他の形式のユーザ入力）を表す（典型的にＵＤＰパケットの形態の）コントロール信号４０６ａ−ｂを送信する。所与のユーザからのコントロール信号は、適当なサーバー（又は複数のサーバーがユーザの入力装置に応答する場合には複数のサーバー）４０２へルーティングされる。図４ａに示すように、コントロール信号４０６ａは、ＳＡＮを経てサーバー４０２へルーティングされる。それとは別に又はそれに加えて、コントロール信号４０６ｂは、ホスティングサービスネットワーク（例えば、イーサネットベースのローカルエリアネットワーク）を経てサーバー４０２へ直接ルーティングされる。それらがどのように送信されるかに関わらず、サーバー（１つ又は複数）は、コントロール信号４０６ａ−ｂに応答してゲーム又はアプリケーションソフトウェアを実行する。図４ａに示されていないが、ファイアウオール（１つ又は複数）及び／又はゲートウェイ（１つ又は複数）のような種々のネットワークコンポーネントは、ホスティングサービス２１０の縁（例えば、ホスティングサービス２１０とインターネット４１０との間）において、及び／又はインターネット４１０と家庭又はオフィスクライアント４１５との間のユーザの家屋２１１の縁において到来するトラフィック及び出て行くトラフィックを処理することができる。実行されたゲーム又はアプリケーションソフトウェアのグラフィック及びオーディオ出力、即ちビデオ映像の新たなシーケンスは、短待ち時間のビデオ圧縮ロジック４０４へ供給され、このロジックは、ここに述べるような短待ち時間のビデオ圧縮技術に基づいてビデオ映像のシーケンスを圧縮し、そして圧縮されたビデオストリームを、典型的に、圧縮された又は非圧縮のオーディオと共に、インターネット４１０を経て（又は、以下に述べるように、一般的なインターネットをバイパスする最適な高速ネットワークサービスを経て）クライアント４１５へ返送する。クライアント４１５における短待ち時間のビデオ解凍ロジック４１２は、次いで、ビデオ及びオーディオストリームを解凍し、その解凍されたビデオストリームをレンダリングし、そして典型的に、その解凍されたオーディオストリームをディスプレイ装置４２２においてプレイする。或いは又、オーディオは、ディスプレイ装置４２２とは個別のスピーカで再生してもよいし、そうでなくてもよい。入力装置４２１及びディスプレイ装置４２２は、図２ａ及び２ｂでは独立した装置として示されているが、ポータブルコンピュータ又は移動装置のようなクライアント装置内に一体化されてもよいことに注意されたい。] 図２ａ 図４ａ
[0086] 家庭又はオフィスクライアント４１５（図２ａ及び２ｂにおいて家庭又はオフィスクライアント２０５として既に述べた）は、非常に安価で且つ低電力の装置で、計算又はグラフィック性能が非常に限定されていると共に、ローカルの大量記憶装置が非常に限定されたものであるか又はそれを全く有していない。対照的に、ＳＡＮ４０３及び複数のＲＡＩＤ４０５に結合された各サーバー４０２は、非常に高い性能のコンピューティングシステムであり、そして実際に、複数のサーバーが並列処理構成で協働的に使用される場合は、保持することのできる計算及びグラフィック処理パワーの量にほぼ制限がなくなる。そして、ユーザにとって知覚的に短待ち時間のビデオ圧縮４０４及び短待ち時間のビデオ圧縮４１２のために、サーバー４０２の計算パワーがユーザに与えられる。ユーザが入力装置４２１のボタンを押すと、ディスプレイ４２２上の映像は、ゲーム又はアプリケーションソフトウェアがローカルで実行されるかのように、知覚的に意義のある遅延を伴わずに、ボタンの押圧に応答して更新される。従って、短待ち時間のビデオ解凍及びコントロール信号ロジック４１３を具現化する非常に低性能のコンピュータ又は安価なチップである家庭又はオフィスクライアント４１５では、ローカルで利用できると思われるリモート位置から効果的な任意の計算パワーがユーザに与えられる。これは、最も進歩したプロセッサ集中の（典型的に新規な）ビデオゲーム及び最高性能のアプリケーションをプレイするパワーをユーザに与える。] 図２ａ
[0087] 図４ｃは、非常に基本的で且つ安価な家庭又はオフィスクライアント装置４６５を示す。この装置は、図４ａ及び４ｂからの家庭又はオフィスクライアント４１５の実施形態である。これは約２インチの長さである。これは、パワーオーバーイーサネット（ＰｏＥ）でイーサネットケーブルとインターフェイスするイーサネットジャック４６２を有し、そこから、インターネットへの電力及び接続が得られる。ネットワークアドレストランスレーション（ＮＡＴ）をサポートするネットワーク内でＮＡＴを実行することができる。オフィス環境では、多数の新規なイーサネットスイッチは、ＰｏＥを有し、そしてＰｏＥをオフィスのイーサネットジャックへ直接持って行く。このような状況では、壁ジャックからクライアント４６５へのイーサネットケーブルが要求されるだけである。利用できるイーサネット接続が（例えば、ＤＳＬ又はケーブルモデムをもつが、ＰｏＥはもたない家庭において）電力を搬送しない場合には、非給電イーサネットケーブル及びＰｏＥ付き出力イーサネットを受け容れる安価な壁「ブリック」（即ち電源）が利用できる。] 図４ａ 図４ｃ
[0088] クライアント４６５は、キーボード、マウス、ゲームコントローラ及び／又はマイクロホン及び／又はヘッドセットのようなブルーツース入力装置４７９とインターフェイスするブルーツースワイヤレスインターフェイスに結合された（図４ａの）コントロール信号ロジック４１３を含む。又、クライアント４６５の一実施形態は、１２０ｆｐｓビデオをサポートできるディスプレイ装置４６８に結合されるビデオを１２０ｆｐｓで出力し、そしてシャッター付き眼鏡４６６に信号を送って（典型的に赤外線により）、各次々のフレームで片方の目に、次いで、他方の目に交互にシャッター作動することができる。ユーザが認知する効果は、ディスプレイスクリーンを「跳び出す」ステレオ３Ｄ映像である。このようなオペレーションをサポートする１つのこのようなディスプレイ装置４６８は、Ｓａｍｓｕｎｇ ＨＬ−Ｔ５０７６Ｓである。各目のビデオストリームは個別であるから、一実施形態では、独立した２つのビデオストリームがホスティングサービス２１０により圧縮され、フレームは、時間的にインターリーブされ、そしてフレームは、クライアント４６５内の独立した２つの解凍プロセスとして解凍される。] 図４ａ
[0089] 又、クライアント４６５は、到来するビデオ及びオーディオを解凍してＨＤＭＩ（高鮮明度マルチメディアインターフェイス）を通して出力する短待ち時間のビデオ解凍ロジック４１２と、ＳＤＴＶ（標準鮮明度テレビジョン）又はＨＤＴＶ（高鮮明度テレビジョン）４６８に差し込まれてＴＶにビデオ及びオーディオを与えるか又はＨＤＭＩをサポートするモニタ４６８に差し込まれるコネクタ４６３とを含む。ユーザのモニタ４６８がＨＤＭＩをサポートしない場合には、ＨＤＭＩ対ＤＶＩ（デジタルビジュアルインターフェイス）を使用することができるが、オーディオが失われる。ＨＤＭＩ規格のもとでは、ディスプレイの能力（例えば、サポートされる解像度、フレームレート）４６４がディスプレイ装置４６８から通信され、この情報は、次いで、インターネット接続４６２を通してホスティングサービス２１０へ返送され、従って、ディスプレイ装置に適したフォーマットで圧縮ビデオをストリーミングすることができる。]
[0090] 図４ｄは、より多くの外部インターフェイスを有する以外は図４ｃに示す家庭又はオフィスクライアント装置４６５と同じである家庭又はオフィスクライアント装置４７５を示す。又、クライアント４７５は、電力に対してＰｏＥを受け容れることもできるし、又は壁に差し込まれる外部電源アダプタ（図示せず）から延びることもできる。クライアント４７５のＵＳＢ入力を使用すると、ビデオカメラ４７７は、圧縮されたビデオをクライアント４７５へ供給し、これは、クライアント４７５によってホスティングサービス２１０へアップロードされ、以下に述べるように使用される。カメラ４７７に内蔵されるのは、以下に述べる圧縮技術を使用した短待ち時間のコンプレッサである。] 図４ｃ 図４ｄ
[0091] インターネット接続としてイーサネットコネクタを有するのに加えて、クライアント４７５は、インターネットへの８０２．１１ｇワイヤレスインターフェイスも有する。両インターフェイスは、ＮＡＴをサポートするネットワーク内でＮＡＴを使用することができる。]
[0092] 又、ビデオ及びオーディオを出力するためにＨＤＭＩコネクタを有するのに加えて、クライアント４７５は、アナログ出力を含む（且つ標準アダプタケーブルでＶＧＡ出力を与える）デュアルリンクＤＶＩ−Ｉコネクタも有する。又、これは、複合ビデオ及びＳ−ビデオのためのアナログ出力も有する。]
[0093] オーディオに対して、クライアント４７５は、左右のアナログステレオＲＣＡジャックを、そしてデジタルオーディオ出力に対して、ＴＯＳＬＩＮＫ出力を有する。]
[0094] 又、入力装置４７９へのブルーツースワイヤレスインターフェイスに加えて、入力装置にインターフェイスするためのＵＳＢジャックも有する。]
[0095] 図４ｅは、クライアント４６５の内部アーキテクチャーの一実施形態を示す。図示された装置の全部又は幾つかを、フィールドプログラマブルロジックアレー、カスタムＡＳＩＣ、或いはカスタム設計又は既製の多数の個別装置で具現化することができる。] 図４ｅ
[0096] ＰｏＥを伴うイーサネット４９７がイーサネットインターフェイス４８１に取り付けられる。ＰｏＥを伴うイーサネット４９７から電力４９９が導出され、クライアント４６５内の残りの装置に接続される。バス４８０は、装置間の通信のための共通バスである。]
[0097] フラッシュ４７６からの小さなクライアントコントロールアプリケーションを実行するコントロールＣＰＵ４８３（ほとんどの場合に、ＲＡＭが埋設された１００ＭＨｚのＭＩＰＳＲ４０００シリーズＣＰＵのような小型のＣＰＵで充分である）は、ネットワーク（即ち、イーサネットインターフェイス）のためのプロトコルスタックを具現化し、又、ホスティングサービス２１０と通信し、そしてクライアント４６５内の全ての装置を構成する。又、これは、入力装置４６９とのインターフェイスを取り扱い、そして必要に応じて、「順方向エラー修正」で保護して、パケットをユーザコントローラデータと共にホスティングサービス２１０へ返送する。又、コントロールＣＰＵ４８３は、パケットトラフィックを監視する（例えば、パケットが失われるか遅延された場合、それらの到着にタイムスタンプも押す）。この情報は、ホスティングサービス２１０へ返送され、従って、ネットワーク接続を常時監視し、それに応じて何を送信するか調整することができる。フラッシュメモリ４７６は、最初に、製造時に、コントロールＣＰＵ４８３のコントロールプログラムがロードされると共に、特定のクライアント４６５ユニットにとって独特のシリアル番号もロードされる。このシリアル番号は、ホスティングサービス２１０がクライアント４６５ユニットを独特に識別できるようにする。]
[0098] ブルーツースインターフェイス４８４は、クライアント４６５の内部にあるそのアンテナを通して入力装置４６９へワイヤレス通信する。]
[0099] ビデオデコンプレッサ４８６は、ここに述べるビデオ解凍を具現化するように構成された短待ち時間のビデオデコンプレッサである。非常に多数のビデオ解凍装置が、既製品として、又はＦＰＧＡ又はカスタムＡＳＩＣへ一体化できる知的プロパティ（ＩＰ）設計として、存在する。Ｈ．２６４デコーダのためのＩＰを提供する１つの会社は、ＮＳＷオーストラリアのオーシャンロジックオブマンリー(Ocean Logic of Manly)である。ＩＰを使用する効果は、ここで使用する圧縮技術が圧縮規格に従わないことである。ある標準的なデコンプレッサは、ここに述べる圧縮技術を受け容れるように構成されるに充分なほど融通性があるが、あるものはそうではない。しかし、ＩＰでは、デコンプレッサを必要に応じて設計し直す上で完全な融通性がある。]
[0100] ビデオデコンプレッサの出力は、ビデオ出力サブシステム４８７に結合され、これは、ビデオをＨＤＭＩインターフェイス４９０のビデオ出力に結合する。]
[0101] オーディオ解凍サブシステム４８８は、入手可能な標準的オーディオデコンプレッサを使用して具現化されるか、又はＩＰとして具現化することもでき、或いはオーディオの解凍は、例えば、Ｖｏｒｂｉｓオーディオデコンプレッサを具現化できるコントロールプロセッサ４８３内で具現化することもできる。]
[0102] オーディオの解凍を具現化する装置は、オーディオ出力サブシステム４８９へ結合され、これは、オーディオをＨＤＭＩインターフェイス４９０のオーディオ出力へ結合する。]
[0103] 図４ｆは、クライアント４７５の内部アーキテクチャーの一実施形態を示す。明らかなように、このアーキテクチャーは、付加的なインターフェイスと、壁に差し込む電源アダプタからの任意の外部ＤＣ電力を除き、クライアント４６５と同じであり、その外部ＤＣ電力は、そのように使用される場合、イーサネットＰｏＥ４９７から到来する電力に取って代わる。クライアント４６５と共通の機能は、以下に説明を繰り返さず、付加的な機能を以下に説明する。] 図４ｆ
[0104] ＣＰＵ４８３は、付加的な装置と通信し、それを構成する。]
[0105] ＷｉＦｉサブシステム４８２は、そのアンテナを通してイーサネット４９７への代替物としてワイヤレスインターネットアクセスを与える。ＷｉＦｉサブシステムは、カリフォルニア州サンタクララのアセロスコミュニケーションズ(Atheros Communications)を含めて幅広い製造者から入手できる。]
[0106] ＵＳＢサブシステム４８５は、ワイヤードＵＳＢ入力装置４７９に対してブルーツース通信の代替物を与える。ＵＳＢサブシステムは、極めて標準的で、ＦＰＧＡ及びＡＳＩＣについて入手容易であり、且つビデオ解凍と同様に、他の機能を遂行する既製装置にしばしば内蔵される。]
[0107] ビデオ出力サブシステム４８７は、クライアント４６５内よりも広範囲なビデオ出力を発生する。これは、ＨＤＭＩ４９０ビデオ出力を与えるのに加えて、ＤＶＩ−Ｉ４９１、Ｓ−ビデオ４９２及び複合ビデオ４９３を与える。又、ＤＶＩ−Ｉ４９１インターフェイスがデジタルビデオに対して使用されるときには、ディスプレイ能力４６４がディスプレイ装置からコントロールＣＰＵ４８３へ返送され、ディスプレイ装置４７８の能力をホスティングサービス２１０に通知できるようにする。ビデオ出力サブシステム４８７により与えられる全てのインターフェイスは、極めて標準的なインターフェイスであり、多数の形態で入手容易である。]
[0108] オーディオ出力サブシステム４８９は、デジタルインターフェイス４９４（Ｓ／ＰＤＩＦ及び／又はＴＯＳＬＩＮＫ）を通してオーディオをデジタルで出力すると共に、ステレオアナログインターフェイス４９５を通してオーディオをアナログ形態で出力する。]
[0109] 往復待ち時間の分析
もちろん、以上の段落を理解するために、入力装置４２１を使用したユーザのアクションと、そのアクションの結果をディスプレイ装置４２０で見るときとの間の往復待ち時間は、７０−８０ｍｓ以下でなければならない。この待ち時間は、ユーザの家屋２１１内の入力装置４２１からホスティングサービス２１０へそしてユーザの家屋２１１へ戻って、ディスプレイ装置４２２へ至る経路における全てのファクタを考慮しなければならない。図４ｂは、信号が進行しなければならない種々のコンポーネント及びネットワークを示し、これらコンポーネント及びネットワークの上には、実際の具現化で予想できる待ち時間を列挙した時間線がある。図４ｂは、重要な経路ルーティングだけを示すように簡略化されていることに注意されたい。システムの他の特徴のために使用されるデータの他のルーティングは、以下で説明する。双頭矢印（例えば、矢印４５３）は、往復待ち時間を表し、単頭矢印（例えば、矢印４５７）は、片道待ち時間を表し、そして「〜」は、近似尺度を示す。列挙した待ち時間を達成できない実世界の状況があるが、米国内における多くのケースでは、ユーザの家屋２１１へのＤＳＬ及びケーブルモデム接続を使用し、次の段落で述べる環境においてこれら待ち時間を達成できることを指摘しなければならない。又、インターネットへのセルラーワイヤレス接続は、図示されたシステムにおいて確実に機能するが、ほとんどの現在のＵＳセルラーデータシステム（ＥＶＤＯのような）は、非常に長い待ち時間を被り、図４ｂに示す待ち時間を達成できないことにも注意されたい。しかしながら、これらの基礎的な原理は、このレベルの待ち時間を具現化できる将来のセルラー技術において具現化することができよう。] 図４ｂ
[0110] ユーザの家屋２１１における入力装置４２１からスタートして、ユーザが入力装置４２１を操作すると、ユーザコントロール信号がクライアント４１５へ送信され（これは、セットトップボックスのようなスタンドアローン装置でもよいし、或いはＰＣ又は移動装置のような別の装置で実行されるソフトウェア又はハードウェアでもよい）、そして（一実施形態ではＵＤＰフォーマットで）パケット化され、そのパケットには、ホスティングサービス２１０に到着するための行先アドレスが与えられる。又、パケットは、コントロール信号がどのユーザから到来するか指示する情報も含む。次いで、コントロール信号のパケット（１つ又は複数）は、ファイアウオール／ルーター／ＮＡＴ（ネットワークアドレストランスレーション）装置４４３を通してＷＡＮインターフェイス４４２へ転送される。ＷＡＮインターフェイス４４２は、ユーザのＩＳＰ（インターネットサービスプロバイダー）によりユーザの家屋２１１に与えられるインターフェイス装置である。ＷＡＮインターフェイス４４２は、ケーブル又はＤＳＬモデム、ＷｉＭａｘトランシーバー、ファイバートランシーバー、セルラーデータインターフェイス、インターネットプロトコル・オーバー・パワーラインインターフェイス、又はインターネットへの多数のインターフェイスの他のものでよい。更に、ファイアウオール／ルーター／ＮＡＴ装置４４３（及び潜在的にＷＡＮインターフェイス４４２）は、クライアント４１５に一体化されてもよい。その一例は、家庭又はオフィスクライアント４１５の機能を具現化するためのソフトウェアと、ある規格（例えば、８０２．１１ｇ）によりインターネットへワイヤレスでルーティング及び接続する手段とを含む移動電話である。]

权利要求:

請求項1
既に進行中のマルチプレーヤ双方向ゲームに加わるためにホスティングサービスセンターによりユーザから要求を受け取るステップと、ユーザに関連した通信チャンネルの待ち時間を含む１組の基準に基づいてユーザが前記マルチプレーヤ双方向ゲーム加わることができるかどうか決定するステップと、前記マルチプレーヤ双方向ゲームをサーバーにロードするステップと、ユーザから受信した制御信号を、前記マルチプレーヤ双方向ゲームをホスティングしているゲームサーバーへ転送するようにインバウンドルーティングネットワークに命令するステップと、ユーザと既にゲームをプレイしている他のプレーヤとの間で前記マルチプレーヤ双方向ゲームに関連したビデオの圧縮を同期させるステップと、を備えた方法。